Real World SOA | David Linthicum | January 2007

MORE ENTRIES

January 2007

January 31, 2007 | Comments: (0)

SOA Project Staffing Plan...Here are some Rough Guidelines

A few of my clients are now looking to staff their first inroads into SOA, their first project where something actually happens beyond the investigation. So...how many people are needed on the project? Who are they? What are their roles? Here are some rough guidelines based on my experience thus far.

The Who (not the band)

You're going to need an eclectic array of skills to do SOA right, including:

Project leader/Architect
Data specialist

Security specialist

Native systems specialist

Service development specialist

BPM/Orchestration specialist

Governance specialists

Testing and deployment specialist

Project archivists

External services specialists

Note: The technology analysis and selection role is innate to all of the above.

The What

While many of the above titles are self explanatory, it does help to define them in a bit more detail. Indeed, roles within the creation of a SOA could be a bit confusing, and the dynamics of a SOA team still needs some understanding.

The project leader/architect, is the person responsible for the delivery of SOA, on time, on budget, and meeting the objectives outline when the investment was made. Typically, this is an IT project manager with an understanding of SOA, but in smaller organizations this could be the enterprise architect or even the CIO.

Data specialists are responsible for all data related analysis, design, and deployment. Typically they have an understanding of all native data layers within the problem domain, as well as metadata, data design (logical and physical), including middleware and data abstraction layers. They also have knowledge of how data is bound to services, and work closely with the service developers.

Security specialists make sure that the security that goes into the SOA is thought about at each stage of the process. SOA security, typically identity management, needs to be systemic, and not an afterthought and a plan must be created and implemented during the project.

Native systems specialists are experts in the native systems that exist in the problem domain. In other words understand the operating systems, hardware, as well as application and networking interfaces. They can do performance tuning, and some light development.

Service development specialists build services using service development tools, and have an understanding of how these services link back to the data layer(s) and link forward to the orchestrations or processes. They are high-end developers, really, who understand how to design, build, test, and deploy services.

BPM/Orchestration specialists are those that both understand the processes as well as automate them within an orchestration layer, such as BPEL tool, or process integration engine. These people need to understand both logical process designs, as well as how to deal with processes yet to be automated, workflow, and implementation or the solution to the process problem.

Governance specialists are just that. They figure out the role governance plays within a SOA, the right technology for the job, and how to implement it in the course of the project. In some instances the use of governance is contraindicated, so you have to be careful here.

Testing and deployment specialist are people who responsible for the development of a formal test plan for the SOA, and test each layer/component to make sure that it's rock solid and ready for production.

Project archivists is a person responsible for keeping track of the various design artifact that pop out of these projects, including: business requirements, application semantic documentation (metadata), services analysis and design documentation, process analysis and design documentation, test planning, etc. This makes it easy for others on SOA projects in the future to learn for the successes and mistakes of others.

External services specialists are people who look outside of the firewall to meet the services needs of the SOA. This means looking at SaaS providers, and other services you don't own, as potential solutions/components within the SOA (enterprise mashups).

How Many?

Your mileage may vary a lot, and my numbers are for a typical project, but here are some initial findings. By the way, my assumptions are: a dozen systems in the problem domain, each having a separate data layers, and are collocated physically. As well as I'm assuming medium complexity for a SOA, reasonable budget, and availability of training and outside consultants.

Project leader/Architect - Typically 1 for the project.

Data specialists - .5 per data layer. Meaning, if you have 12 different databases or applications, you need 6.

Security specialists - 2 per project. One who understand the existing security, and one who understands the special security requirements of SOA.

Native systems specialists - 1 for each type of system. Meaning if you have a mainframe, Unix, and Windows NT, you’ll need at least 3.

Service development specialists - 1 for every 100 services to be deployed. Typically you’re going to do a 1000 in a project that big, thus figure on 10 services development specialist. Yes, I said 10.

BPM/Orchestration specialists - 4 per project. One who understands and documents existing services, one to document new services, and two to build the services into the orchestration layer.

Governance specialists - 1 per project.

Testing and deployment specialists - 4 per project. One to write the plan, and 3 to execute on it.

Project archivists - 1 per project.

External services specialists - 1 per project.

Hope this helps. As new data points and experiences become available, I'll let you know.

Posted by Dave Linthicum on January 31, 2007 07:28 AM

January 30, 2007 | Comments: (0)

Too Much SOA Technology?

I came across Steve Jones' blog post entitled "Stop with the damn SOA technology." Steve, you had me at "Stop." He is commenting on this post by Joe McKendrick, "Is SOA too much for the IT department?"

From Steve’s post:

"The real problem, which is referenced but then sort of glossed over, is that IT needs to be looking well away from the technology and away from the projects and doing two things. Firstly IT should be looking to get the investment to make changes by [economizing] on those parts of the budget that they do control (i.e. support, development and infrastructure of existing systems) and Secondly IT should be looking to do the cheap things that will have the largest impact. This means [organizational] and governance changes and understanding what the business service architecture should be."

Clearly, the issue we are dealing with is our attempt to do some great things within our firewalls, and avoiding the temptation to just toss technology at the problem. I remember back in the EAI days, when consulting with companies looking to solve their integration problems, those that were successful thought of the technology as a means to execute on a plan, and not the plan itself. The technology is much more effective if leveraged within the proper context.

Indeed, things are not healthy right now when considering most rank-and-file SOA initiatives, as I'm finding. Even the consultants from the larger firms, who should look out for their clients, are getting onboard the "technology first" bandwagon, and spending their billable hours talking about governance tools and ESBs, versus issues that are core and fundamental to the business and current instance of IT. That can't end well.

"If you think 'well we can't make any changes but at least we can use SOA technologies on this project, that will help won't it?' then you are deluding yourself."

I hear you brother.

Posted by Dave Linthicum on January 30, 2007 03:46 AM

January 29, 2007 | Comments: (0)

Misconceptions about SOA

Download file

Posted by Dave Linthicum on January 29, 2007 08:10 PM

January 29, 2007 | Comments: (0)

"SOA Jumpstart" Web Tutorial...Now Open to the Public

No, this is not a "SOA hype" Webinar attempting to sell something. I'm doing this "Web Tutorial" for a few of my current clients, by request, and they said it was okay for me to open it up to the public. So, click-in and learn something. You can find the info here.

Date: Thursday, February 15, 2007
Time: 1:00 PM - 2:00 PM EST

It's a learning and introductory session on SOA. Here is the description:

Many may understand the notion of SOA, but very few have any idea how to get there. Truthbetold, there is no hard and fast rule as to how one builds a SOA in their organization.

The purpose of this Webinar is to provide a step-by-step guide for those who design and build SOAs. This Webinar will walk them through all of the logical steps, including defining key artifacts and providing examples of those artifacts (e.g., design documents). In essence, this Webinar serves as a meta-methodology of sorts, taking the mystery out of moving an organization to a more service-oriented and real-time state.

Posted by Dave Linthicum on January 29, 2007 05:23 PM

January 29, 2007 | Comments: (0)

Is your SOA Loose?

I've had a few people ask me about loose coupling and SOA recently. There seems to be some confusion around this concept.

With the advent of web services and SOA we've been seeking to create architectures and systems that are more loosely coupled. Loosely coupled systems provide many advantages including support for late or dynamically binding to other component while running, and can mediate the difference in the component's structure, security model, protocols, and semantics, thus abstracting volatility.

This is in contrast to compile-time or runtime binding, which requires that you bind the components at compile time or runtime (synchronous calls) respectively and also requires that changes be designed into all components at the same time due to the dependencies. As you can imagine, this type of coupling makes testing and component changes much more difficult.

The advantages of loosely coupled architectures, as found within many SOAs (if they are designed and built correctly), are apparent to many of us who have built architectures and systems in the past, at least from a technical perspective. However, they have business value as well.

First and foremost, a loosely coupled architecture allows you to replace components, or change components, without having to make reflective changes to other components in the architecture/systems. This means businesses can change their business systems as needed, with much more agility than if the architecture/systems was more tightly coupled.

Second, developers can pick and choose the right enabling technology for the job without having concern themselves with technical dependencies, such as security models. Thus, you can build new components using J2EE, which will work and play well with other components written in Cobol or perhaps C++. Same goes for persistence layers, middleware, protocols, etc.. You can mix and match to exactly meet your needs, even leverage services that may exist outside of your organization without regard for how that service was created, how it communicates, nor where it is running.

Finally, with this degree of independence components are protected from each other and can better recover from component failure. If the SOA is designed correctly, the failure of a single component should not take down other components in the system. Thus, loose coupling creates architectures that are more resilient. Moreover, this also lends itself better to creating failover subsystem, moving from one instance of a component to another without affecting the other components in the SOA.

It should be noted, however, that not all tight coupling is bad. Indeed, in some cases it makes sense to more tightly couple components, such as when the dependencies are critical to the design. An example would be two services that can't work apart, and must function as one, and thus are better tightly coupled. You have to look at your requirement, and then determine the degree of coupling required in your architecture, and it may not always be loose coupling.

Posted by Dave Linthicum on January 29, 2007 04:36 AM

January 26, 2007 | Comments: (0)

"What's holding back SOA?"

Bert Latamore of Computer World wrote this article, about the fact that SOA is happening later than expected.

"Since about 2003, service-oriented architecture (SOA) has been touted as the network-based, next-generation computing environment, replacing the client/server architecture of the 1990s.
Industry leaders like Bill Gates have made brave predictions about a future in which their applications will live across the Internet, and developers will meet specific needs by combining functions from these networked applications on an almost ad hoc basis.

So what has happened in the past three or four years? On the surface, it might seem very little."

First of all, I'm not sure SOA is an evolution from client/server. Having written both client/server books and SOA books, the notions are very different. However, I won't hammer the author on that here.

Truth-be-told the article is correct in that the adoption of SOA has not met the expectations of the hype. But when does it ever? I've hit on that issue to death here...the fact that SOA is a huge systemic change to enterprise architecture and, as such, won't be something that happens overnight. I think it's most likely a 5 to 10 year evolution of existing IT to more service-oriented approaches, and I think most enterprises are going to take baby steps.

In fact, you may find that the buzzword of "SOA" falls out of favor with the press and hype-oriented people in our industry, just as it begins to pay for itself within the enterprise. That's not a bad thing. Being in this business now for 24 years, that's become SOP.

The article goes on to discuss the fact that we really don't have a single definition of SOA, as of now, and that limiting its success.

"Even its proponents don't agree on a single SOA vision yet,"

Clearly, this is an issue. The hype, and the redefining of SOA for a purpose, approach, or technology, is limiting the adoption. I think many end users are waiting for one common vision for SOA before diving in. The SOA movement, in general, seems chaotic with many mixed messages. Not sure how to solve that one, perhaps if everyone just read my blog; the world would be a better place for SOA. :-)

"Like it or not, SOA is approaching rapidly, driven by the basic business need to improve efficiency, respond faster and do more with less. And over the next decade, nearly every application and technology used today will need to evolve rapidly to keep up."

Good quote to close on. Have a good weekend everybody, new Podcast on Monday night.

Posted by Dave Linthicum on January 26, 2007 05:50 AM

January 25, 2007 | Comments: (0)

Are we Ready for an Open SOA Methodology?

As I've been consulting with end user organizations, I've been thinking methodology...approaches, steps, procedures, whatever you want to call some sort of structured approach to implementing a SOA that insures care is taken when gathering requirements, defining/designing, and selecting the right technology. Indeed you may remember 12 Steps to SOA, now broken down to provide more details.

So, for those of you who don't remember just what a methodology is, Wikipedia defines it as:

"Methodology is defined as (1) 'a body of methods, rules, and postulates employed by a discipline', (2) 'a particular procedure or set of procedures', or (3) 'the analysis of the principles or procedures of inquiry in a particular field'[1]. The common idea here is the collection, the comparative study, and the critique of the individual methods that are used in a given discipline or field of inquiry."

In looking at the other SOA consulting firms out there, most have methodologies, formal or informal. All of these methodologies are different, but all with the primary value of using a structured consistent approach for many different problem domains. I would argue, however, that some of those SOA methodologies out there need some work.

With so many different methodologies emerging, what I'm proposing is that they come together as a standard "open methodology," driven by the SOA practitioners and not just the vendors or consultants, very much like a wiki.

For instance, I open up "Steps[TM]," put it out there for use, review, and edit. Other firms who have SOA methodologies are invited to do the same. End users can pick and choose the steps, deliverables, or procedures they would like to leverage, and return there experiences back to the open method/wiki...such as "this worked well," "this did not," "here is the way I recorded metadata," "here is the way I recorded processes."

As such, the methodology evolves into something more practical and useful, with real experience behind it that's shared among the practitioners. Other things included could be open source design tools, shared services repositories, and gateways to external Web-delivered services.

So, how do we go about doing this? First, you have to give this notion a cool TLA, I'm thinking Open SOA Methodology, or OSM. Second, set up the infrastructure for sharing, I'm thinking a wiki approach is best. Finally, put some initial content out there to get things rolling. I'm happy to do that.

While some may be tempted to toss this over to a standards body, I really think this would be much more valuable if the end users drove this dynamically, and not have this in committee after committee.

Seems like a good idea to me.

Posted by Dave Linthicum on January 25, 2007 05:59 AM

January 22, 2007 | Comments: (0)

Selling SOA

I caught this piece today, "Selling SOA to a CEO," by IBM's Sandy Carter, and found some things that I would like to emphasis pertaining to selling SOA at the corporate level.

"Still, as many IT managers have learned, without executive endorsement, an SOA will be relegated to the confines of IT as opposed to being recognized as an organization-wide business strategy. While no two organizations are exactly alike, there are consistent themes that arise -- and pitfalls to avoid -- when aiming for approval to build an SOA."

Let's face it, CEOs have heard all of the buzzwords before, such as client/server, data mining, intranet, knowledge management, object-oriented, approving huge budgets for training, consultants, staffing, and new technology. But still, as told to me by a CEO friend of mine, "...can't understand why it takes a year to alter a business process. Also, why everything funded in the last 10 years, was delivered late and over budget"...can you say "ERP?"

Thus, CEOs can't help but be a bit gun shy when we parade yet another "revolution in computing," this time SOA, and have our hands out seeking funding, commitment, and acceptance of risk. If you're even the least bit empathetic, you'll understand why they are becoming more skeptical.

So, now that it's time again to do some things different, you'll find that the selling is a bit harder than it was in the past, and Sandy has a few good suggestions. My favorite being:

"1. Don't call it SOA: explain the value and benefits in business terms that reflect the organization's goals -- such as cost reduction, productivity, competitive advantage, etc. -- before diving into a technical conversation."

Good point, and really the fact that you're selling the notion of fixing existing issues, becoming more efficient, and not just layering in new technology for technology's sake.

Sandy has something there, indeed I've found it much more effective to sell the ROI than the buzzword, especially to business leaders that are more concerned about earnings per share than governance, and more inclined to say yes to "improvement" than yes to "SOA."

It's all in how you say it.

Posted by Dave Linthicum on January 22, 2007 04:46 PM

January 22, 2007 | Comments: (0)

More on the Convergence of SOA, SaaS, and Web 2.0

Download file

Posted by Dave Linthicum on January 22, 2007 04:11 PM

January 21, 2007 | Comments: (0)

Help Us Change...to SOA

Demand for SOA-Related Change Management Services Grows

The demand for organizational change management (CM) services related to SOA is steadily increasing and will continue to grow in the coming years, according to a new study from IDC.

"As clients move up the SOA adoption curve and start to engage in broader enterprise-wide and more strategic engagements with a compounding level of business complexity, managing change with focus on the people and organizational factors becomes increasingly critical."

"This report also reveals that the transition to SOA is not always an easy one. Companies are realizing that implementing SOA means far more than addressing such tangible and relatively straightforward problems as integration and consolidation of applications. The burden of SOA implementation typically falls most heavily on the people and organizational side of the enterprise, where new skills and responsibilities have to be introduced along with attention to the business requirements, and to the much tighter relationship between IT and business."

This report agrees with what I've been seeing in the market, more of an awakening to reality, really. While the relatively new notion of SOA is driving that awakening, it's really about tired and static architectures becoming more adaptable to business. That means change, and somebody has to drive that change within organizations. That's why I decided to do what I'm doing now, and others are moving in the same direction.

Posted by Dave Linthicum on January 21, 2007 06:21 AM

January 19, 2007 | Comments: (0)

New SOA Practitioner's Corner on the SOA Report Podcast...Featuring You

I've kind of left other people out of the SOA Report Podcast within the past several months. The Podcast is typically under 10 minutes; thus it's difficult to invite guests. However, I've also have had many SOA practitioners, with good content, ask to contribute to the Podcast, including vendors, users, consultants, and those that are very confused about SOA.

As a result, I'm going to open up the voice mail line again for the SOA Report Podcast, but I would ask that only "SOA practitioners," call in, meaning those from end user organizations looking to implement SOA or consultants working on a SOA project for an end user organization. PR people who are tempted to read press releases on this voice mail line should just e-mail me the release, please.

Suggested topics would include:

- A description of your problem domain, and how you're approaching it.
- Issues related to getting approval within your organization for a SOA.
- Experience related to implementation...what's working and what's not.
- Trials and tribulations with specific technology.
- Success stories, and how you got there.
- People issues around the implementation of SOA.
- Design tools...what's working?

I think you get the idea. Your messages should be no more than 3 mins long, and please include your e-mail address for validation (I will clip that out of your message). However, you may or may not choose to leave your name and/or company name on the message, and thus won't be included in the Podcast.

Other things:

- Messages that use the term "SOA 2.0" will be deleted immediately.
- You may only use the word "paradigm" no more than 3 times.
- No 4 letter words, unless something really, really bad happened.

The voice mail line is: 703.531.8714 Skype ID: soaexpertpodcast

Call now, call often.

Posted by Dave Linthicum on January 19, 2007 09:24 AM

January 19, 2007 | Comments: (0)

Five surefire ways to make your SOA a success

"SOA resists easy answers. But a handful of guiding principles can keep the most important initiative you may ever launch on track"

Just had my "Five surefire ways"... article published in InfoWorld. Eric Knorr did a great job editing this piece, which was based on my talk at the SOA Executive Forum a few months back.

From the article:

"SOA isn't just trendy, it's here and it's working. Most large enterprises have already launched some sort of SOA initiative, the objective being an agile architecture that can respond to business needs in near-real time. Along the way, SOA provides a means for fixing systems that have languished in a dysfunctional state for years. No wonder IDC expects spending on SOA-related software to reach nearly $15 billion by 2009."

The purpose of the article was to focus on the practical aspects of SOA, in essence what business problem we're looking to solve, and how we can approach the problem. It was not about governance, ESB, or even, of the hype that's going on right now...albeit that the technology is important, the focus should be on issues that are much more rudimentary at this point.

"Organizations implement SOA for two major reasons. The first reason is to gain the ability to save development dollars through reuse of services. These services may have been built inside or outside of the company, and the more services that are reusable from system to system, the greater the ROI. The second reason is the ability to change IT infrastructure faster and adapt to shifting needs of the business. This provides a huge strategic advantage and can give the business a better chance of survival in the long-term."

I hope the article helps. Let me know what you think.

Posted by Dave Linthicum on January 19, 2007 08:50 AM

January 18, 2007 | Comments: (0)

More Validation for the Convergence of SOA, SaaS, and Web 2.0...The Global SOA

I was happy to read Dion Hinchcliffe's posting of last month: "2007: The year enterprises open their SOAs to the Internet?" sorry I missed it when it posted. Also Joe McKendrick's follow up comments and Phil Wainewright's post which reflects the same notion.

Joe states:

"So, Web services started out as an external play, was turned into an internal play, and now things will be turned inside-out to once again."

Of course, this notion has been on my radar screen for a few years now, consider my past posts:

Web 2.0 = The Global SOA

Can your Enterprise See the Emerging Web?

More Synergy between Mashups and SOA

As I've stated a few times, this is one of the most exciting aspects of the emerging notion of SOA, the ability to work and play well with services outside of the firewall, and do so transparently...inside-out and outside-in. This does not happen by evolution, by the way, it's going to take some good work from the architects to design their SOAs to accommodate external services, as well as open their services up to remote systems.

So, if we all agree that this is coming, what can you do?

First, accept the notion that it's okay to leverage services that are hosted on the Internet as part of your SOA, and it's okay to expose services to systems you don't control. Normal security management needs to apply, of course. The largest issue, unfortunately, is acceptance. The technology is not that complex, many of the political and people issues are.

Second, create a strategy for the consumption and management of outside-in services, as well as the exposure of inside-out services, including how you'll deal with semantic management, security, transactions, etc. Same good SOA requirements work applies here.

Finally, create a proof of concept now. This does a few things including getting you through the initial learning process and providing proof points as to the feasibility of leveraging remote services, as well as exposing services. This is the fun part, by the way.

Posted by Dave Linthicum on January 18, 2007 06:26 AM

January 16, 2007 | Comments: (0)

SOA Spending in 2007

Download file

Posted by Dave Linthicum on January 16, 2007 06:31 PM

January 16, 2007 | Comments: (0)

When Thinking SOA Performance..Don't Think REST vs. SOAP...Think Design

There has been an ongoing debate over the value of REST and the value of SOAP, when it comes to SOA. Ss much as been said about it, I did not think I could add much value to the discussion.

Of course, the issues go well beyond performance, but lately I've been working with a number of companies that are focused on just that...SOA performance.

Indeed, Web Services are slow. There, I said it. They are very synchronous in nature, and do cause concern for those building a SOA around Web services (Keep in mind that Web services are only one type of technology you may use to build your SOA). However, tossing new standards and technology at the problem won't get you there. Instead, you need to think at a more fundamental level...the design of the service.

Truth-be-told is most developers have gotten accustomed to having commodity resources available in their deployment environments, meaning memory, CPU, bandwidth, I/O, etc., and many don't think "service efficiencies" when designing (if they do design), programming, and deploying a Web service. In fact I'm reviewing services now that with just some rethinking in terms of how they leverage resources, including when, how often, and why...they are increasing service performance by 200 percent in many cases. Also, the whole "too course grained" or "too fine grained" thing becomes issues as well.

The key issue is that most service developers don't understand service design yet, and build them without a clear understanding of the consequences of some of their design decisions. They build them, deploy them, get them working and any performance issues can be blamed on the inefficiencies of SOAP. While SOAP can take part of the wrap, as can the overall set of standards, most of the issues that cause performance problems can be tracked back a human with a compiler.

To that end, here are some general guidelines:

1. Design the service to minimize the number of times communications is required with other services, devices, or the container.
2. Consider organic growth of the data and amount of data transmission. Something working well today at 10 transactions-per-second, may die at 100.
3. Perform a practical number of POC performance tests using several design approaches. Make sure to address granularity.
4. Try different enabling standards. Don’t rely on others to tell you that something is faster, prove it within your own problem domain.
5. Think through your service design, and account for efficiency. Perhaps consider CMM level 3 design and review patterns.
6. Don’t be afraid to try new things…a small increase in performance could save you from a lot of problems down the road.
7. Make sure you decompose your services considering usability, functionality, and performance.

Posted by Dave Linthicum on January 16, 2007 09:06 AM

January 13, 2007 | Comments: (0)

Budgeting for SOA Success

I was a bit confused when this article, "Budgeting for SOA Success," my article, posted on the Computer World site. Indeed I remember writing it, but I thought it was for InfoWorld. My bad, I'm sure. Truth-be-told I need to pay more attention to whom I'm sending articles to, good resolution for 2007 I'm thinking.

As confusing was the 11/01/2007 14:03:51 post date on the article. Somebody forgot the reset the time on the server, or my future self is writing and posting articles...now that would be cool. I would have less hair, but more information.

Joe McKendrick had some good insights into my article. I urge you to read his thoughts, and that's actually how I saw that the article had posted in the first place.

The purpose of the article was to provide a prediction as to how enterprises would spend their hard-earned budgets on SOA in 2007.

A few tidbits:

"2007, however, will witness a significant surge in SOA spending, as early adopters evolve POC (proof of concept) implementations into more robust deployments and late adopters buy into the architectural shift. Lack of insight and foresight, however, will spur many enterprises to divert too many dollars to areas that will prove less fruitful in ensuring the long-term success of their SOA."

I'm specially speaking about the hype issue, and the fact that far too much time is spent on looking at the emerging technology, and not enough time on looking at your own architectural issues. One of the great things about SOA is that it provides you with an opportunity to evaluate your own status, and provides a great excuse to fix it.

To that end...

..."too much will be spent on hype -- again. Many who should be heads-down in their own requirements will get caught playing 'follow the buzzword' or 'manage by magazine.' This means excesses for steering committees, conferences, and POCs to the detriment of real work getting done."

I know I sound like a broken record, but SOA is hard when you get right down to it. It's complex distributed computing and requires some basic architectural changes...many that have roots in traditional enterprises architecture and require much the same discipline.

However, there is plenty of new and innovative stuff to go around, indeed...

..."few companies will spend enough examining the emerging Web, specifically SaaS (software as a service) and Web services marketplaces. Many enterprise apps can be outsourced, either to SaaS providers accessible through the Web or as sets of services that may be abstracted directly into your SOA. Indeed, of all the aspects to budget for, tapping the emerging Web could provide the highest ROI. Position your SOA to bank on it."

One of the byproducts of a SOA, is the ability to work and play well with the emerging Web, including SaaS delivered applications and services. These are money-in-the-bank for many enterprises; you just need to plan to take advantage of them.

Posted by Dave Linthicum on January 13, 2007 06:04 AM

January 12, 2007 | Comments: (0)

Speed Up Your SOAP with WS-MTOM

For years those building SOAs have said that "SOAP is too slow" and Web Services are just the icing on the SOAP cake. However, as somebody who's out there in the SOA project world right now I think it's fair to say that many SOAs are indeed slow, and that performance is always an issue when dealing with Web services.

However, SOAP could be speeding up. Enter WS-MTOM, or the development of the SOAP Message Transmission Optimization Mechanism specification. MTOM offers composability of base64 with the transport efficiency of SOAP with attachments. However, WS-MTOM wasn't tied into the rest of the Web Services architecture: there was no standard way for services to advertise that they were "MTOM ready," until now.

IBM and Microsoft have recently submitted WS-MTOMPolicy to W3C. This has now been acknowledged by W3C, which clears the way for a standardization effort around this issue.

From the spec:

"This specification describes a domain-specific policy assertion that indicates endpoint support of the optimized MIME multipart/ related serialization of SOAP messages defined in section 3 of the SOAP Message Transmission Optimization Mechanism specification. This policy assertion can be specified within a policy alternative as defined in WS-Policy Framework and attached to a WSDL description as defined in WS-PolicyAttachment."

So, take WS-Policy and MTOM, and it's soon going to be possible for Web Services across enterprise boundaries to advertise their MTOM capabilities. Thus, SOAP will be faster. Thus, Web services will be faster. Thus, our SOAs will be faster. That's a good thing.

Posted by Dave Linthicum on January 12, 2007 05:46 AM

January 11, 2007 | Comments: (0)

"SOA and BPM Converging"...Duh

According to Forester, SOA and BPM are converging to the point that the "integration suite" market category is obsolete and is being replaced by emerging "integration-centric business process management suite" (IC-BPMS). You can see the complete article in Jax Magazine here.

"'The products in this category have lowered the barrier between integration and new application development - particularly, the development of composite applications that extend the mindset of the organization to complete, cross-functional business processes,' write the report's authors, Forrester analysts Ken Vollmer and Henry Peyret."

"The products in the new IC-BPMS category are 'not your Dad's EAI,' Forrester analysts wrote in the report on the convergence titled, 'The Forrester Wave: Integration-Centric Business Process Management Suites, Q4 2006 - IT View and Business View Tech Choice.'"

Not your "Dad's EAI?"

Okay guys, let me be very clear. First, the use of BPM has always been a part of the notion of EAI, and indeed has always really been a part of SOA. Thus, pointing this out today, in 2007, is like pointing out that fire is hot...it's not new, and rather obvious. Here are some key data points:

From my EAI book, now almost 10 years old:

"While some may dispute the relevance of BPM and EAI, we would argue that BPM is ultimately where EAI is heading."

Also, from my blog this summer:

"Truth-be-told the discipline of BPM is really a part of everything having to do with integration, including EAI, B2B, and yes SOA. SOA's ultimate goal is to provide abstraction layers that works with a business process (or orchestration) layer, allowing those who want to change processes to do so at that layer, and have the changes reflect back on the underlying information flows and service invocations."

Moreover, I'm doing a keynote talk at the Business Process Management Conference April 24-26, 2007, on this very topic. SOA needs BPM, and the other way around.

Okay, I know, you get it. :-) I'll shut up.

So, why does this drive me crazy? I think we just need to be at a much higher level of sophistication by now, both in the understanding of what SOA is, and how to use it in a sentence.

Truth of the matter is that from the beginning BPM has been systemic to SOA. SOA is not worth much without the notion of process management, and process management, if you ask me, is not worth much without the notion of SOA, or at least integration. I even run into product vendors today who tell my about their "new innovation," the "marriage of BPM and integration." Unfortunately, that's neither new or innovative, albeit valuable and logical.

Posted by Dave Linthicum on January 11, 2007 06:20 AM

January 09, 2007 | Comments: (0)

Good SOA...Like Good Wine...Takes Years to Perfect

I caught this article on CRM today, highlighting some recent data around the state of SOA, and the potential value. Indeed, the core idea being:

"The transition to SOA is a multi-faceted programme that will take many years to attain, but organizations must begin to plan their SOA initiatives today, and acquire the business and technical skills that are required for success."

The article goes on to state:

"'The adoption of SOA has significant potential to improve the value organizations derive from their IT investments, in terms of increased flexibility, improved use of assets, alignment with business objectives, and reduced integration costs', says Mike Thompson, Business Process Management (BPM) Practice Director and co-author of the study. 'However, there is still a considerable degree of hype and misunderstanding around the topic, with consequent confusion as to the exact definition of a SOA, and more importantly, how to begin to realize these benefits.'"

This is what I've been saying, as you know. The core issue is that most organizations who need SOA, neither understand it, nor have the first clue as how to move down that path. The vendor hype is causing most of this confusion, as well as inflated expectations, and an oversimplification of the problem.

Furthermore, many organizations that need SOA are missing key skill in order to make SOA a success.

"Clearly, with a step change in approach there will be technical issues, with the lack of in-house expertise often being cited as one of the major barriers to the adoption of SOA."

Also, the pain of early adoption of any technology.

"Early adopters have also encountered problems around security, service performance, reliability, and data management. Security is a particular concern, especially as the IT function has spent a large amount of time, effort, and money on tackling security issues, and there are concerns that SOA might open up new gaps within the implemented systems."

Summing up:

"When deploying SOA it pays to start small, but think big, and to choose a business problem that SOA can help resolve as a starting point."

Can't say it better than that.

Posted by Dave Linthicum on January 9, 2007 06:53 AM

January 09, 2007 | Comments: (0)

Are you building a real SOA?

Download file

Posted by Dave Linthicum on January 9, 2007 04:50 AM

January 07, 2007 | Comments: (0)

Are you Building a JBOWS or a True SOA?

I enjoyed Joe McKendrick's blog where he sited a current study by Saugatuck Technology research that points out that SOA is still evolving, and that it's going to take a few years before the true value of SOA is a reality for most enterprises. Indeed, Joe goes on to say that many of the so called SOA implementations today are JBOWS, or "Just a Bunch of Web Services." Let's see, where have we heard that before?

From the study:

"However, according to Saugatuck, upon further probing, 'it became clear that many are merely managing a collection of Web services, and have yet to make a strong commitment to SOA as a management discipline — as opposed to an integration technology.'"

Truth-be-told SOA is, as I've said many times here, a true systemic change in the way you approach enterprise architecture. That's where the value is, and not just Web service-enabling you systems, or purchasing and implementing products with the "SOA hype label" bound to them (can you say governance? Can you say ESB?). It's the implementation of several layers of concepts as well as technology, custom fit to your requirements, and carefully considered given that this will be your foundation of IT going forward. Nothing more, nothing less.

So, are you building a JBOWS, or a true SOA? Here are a few things to consider:

- Are the services a true representation of the core behaviors found in your key enterprise systems, as well as new services required to provide other critical behaviors?
- Have those services been abstracted for most foreseeable uses?
- Is your information/data managed in such a way that you're loosely coupled from the underlying physical schemas?
- Are the services combinable into composites, and are those composites well defined?
- Is there a plan for governance and security, managing the use the services?
- Are both the information and services abstract-able to an orchestration/process layer for configuration-oriented agility of most of the IT assets?

I think you'll find that must early implementations of, at least the label of SOA, are actually "JBOWS." Not to worry, JBOWS can be a good start towards a SOA. Just know, you're not there yet.

Posted by Dave Linthicum on January 7, 2007 05:52 AM

January 05, 2007 | Comments: (0)

Why the Government could Lead Us to the SOA Promised Land

What? The US Government leading technology? Not sure that makes sense right? Wrong.

In working on a few projects, both commercial and government, I've come to the conclusion that many of the government organizations are both bullish on SOA, and are actually blazing trails that most in the commercial sector has yet to attempt.

This is very different from the government IT work of my youth, where they were more about commodity and short-term cost savings, than long term strategic use of technology. However, things have changed, and for the better. As a tax payer, I could not be happier.

The core patterns that I'm seeing with my government clients are:

Holistic use of SOA to manage IT assets intra-agency. Meaning that they are looking to leverage SOA for a specific domain, typically < 100 systems, but greater than 50.

Holistic use of SOA to manage IT assets inter-agency. Meaning that they are looking to share services and information across government, and are looking to do this to provide long term value.

Ability to attract and maintain key SOA talent to move them towards their goals. This means key contractors, and key government hires...people who seem to understand the larger issues, as well as the tactics.

The funding required to accomplish the task.

Clear understanding of the risks, and the benefits.

Of course, like the commercial world these guys will have their challenges moving forward, and it's a marathon not a sprint, a journey not a project (okay, I'll stop saying this in 2007). However, it's most encouraging to see key government entities cleaning up their architectural acts, leveraging the pieces of the notion of SOA that will work for them. In the long term, things should run better and cheaper, and these guys could provide key data points that will benefit implementation of SOA in the corporate world.

Posted by Dave Linthicum on January 5, 2007 05:35 AM

January 04, 2007 | Comments: (0)

Common Service Descriptions could be a key to Governance

When reviewing both WSDL and UDDI, the information you're able to obtain about services are very low level indeed, allowing you to both discover and bind to a service...let's face it, that is what they were designed to do. However, neither WSDL nor UDDI provides the "meta" information that will prove useful as we leverage both private and public services. We need a common standard.

There are a few more dimensions we need to address including: semantics, purpose, authentication, dependencies, and service levels. These by the way, are only basic suggestions, other dimensions and even sub-dimensions are all allowable.

Semantics, is a no brainer and it's been known for awhile that semantics are a weak point of Web services. Today we are attempting to solve this problem with new standards such as The Semantic Web, or more often through proprietary mechanisms, so I really don't need to sell this dimension. This is a pain point for most service-oriented architects.

Purpose means that we have a common notion of the purpose of the service, such as a service that written to update cash in an accounting system, or a service that controls a large inventory system. Here we should document the uses of the service, examples, and any calling information needed.

Authentication would provide the security element to a service, including who's authorized to use it, identity management issues, and any special security issues such as the use of encryption.

Dependencies would define any other services encapsulated inside of a service where the calling service is dependent upon. For instance, an inventory control service may leverage a public service to determine the date and time, that needs to be documented as a dependency for obvious reasons (e.g., that service dies so does your service).

Finally, we need to define service levels. In other words, the service levels you can expect from a particular service including standard outages and accessibility issues, such as limited bandwidth. This will allow those creating a composite application around a group of services to determine the service levels of the composite application, which is only as good as the services that make up the composite application.

Clearly we need to go a few more levels of detail down to better define the notion of service description as well as the properties we need to track within each service. Perhaps we can meld this into an existing standard, much in the same way metadata is moving towards a standard.

However, I suspect it will still be the Wild West out there for awhile as SOAs moves out of the playground and into business critical production systems, which seems to be occuring now. Thus, we better have some sense of how to define, share, and leverage service descriptions in a common way, or it will be a very confusing world.

Posted by Dave Linthicum on January 4, 2007 05:52 AM

January 01, 2007 | Comments: (0)

Reaction to "Should You Fire your Enterprise Architect" Posting...Grade on a Curve?

I love Google alerts, because I can figure out who's reposting or linking to this blog, and get some new perspectives. Typically they are "Dave says this, isn't it great?" Or, "Dave must love our product because he says this."

However, there was a large, somewhat grumpy reaction from my "Should you fire..." posting on December 4th. Beside a few comments, Eric Roch took me to task in his blog. I never heard of Eric, but I do read James McGovern's blog, and he pointed me there.

"Eric Roch who is CTO at Perficient inappropriately amplified a comment made by David Linthicum suggesting that Enterprise Architects be fired if they are not promoting Service Oriented Architecture. Another perspective is surely needed..."

Eric states:

"He lists a set of questions to help decide if the Enterprise Architect should be fired.
I personally don't believe there are any companies that can answer yes to all these questions, so I guess all our architects should be looking for work. Is it really an architect's job to determine the ROI of SOA? Does anyone really have a complete service, semantic and process understanding of the enterprise?"

I think Eric brings up an interesting point, but a bit defeatist, if you ask me. Moreover, it's contrary to the organizations I'm working with, who do indeed have progressive architectures that align, or will align with their business. It's not that hard.

However, many organizations are getting bad advice, and IT architectures continue to hinder the growth and agility of many businesses. That's the key point I was attempting to make, and there are many studies that prove this out.

In many modern global 2000 companies, the enterprise architectures are badly broken and hinder the businesses ability to change. For instance, a recent survey by the Business Performance Management Institute found that only 11 percent of executives say they're able to keep up with business demand to change technology-enabled processes. 40 percent of which, according to the survey, are currently in need of IT attention. Worse, 36 percent report that their company's IT departments are having either "significant difficulties" (27 percent) or "can't keep up at all" (9 percent). This information is from CIO Magazine.

The reality is that IT has done a poor job of supporting the business when considering the amount of latency apparent when change needs to occur. CEOs pull their hair out when their IT group talks about years not months to add product lines, change markets, or merge with other companies. Indeed, in many companies, the IT shop is the single limiting factor for business success, and can kill the business if left to continue as-is.

Eric goes on to call my posting "inflammatory." The purpose of the post was not as much to be inflammatory, but thought provoking. Indeed, many organizations are not actively working the issues with the architecture, and the business is suffering for it. SOA is a fine approach, but in many instances the issues are much more fundamental. I think I should have made that more clear.

As I stated in my blog a few times, for some reason the discipline of enterprise architecture has morphed into more of a management practice, and the fundamental flaws within many enterprise architectures are not being addressed. SOA is one approach, but in some instances is not indicated, thus why I asked for an ROI study as part of the "test." However, there is always a need for good enterprise architecture.

Okay, I get it. I was a college professor for 8 years, so I know when tests are too hard and I need to grade on curve. So, send in your scores, or post them as comments here...I'll adjust the pass fail down to something more obtainable for the enterprise architects out there, according to Eric.

However, I'm sure many enterprise architects will indeed pass, and do have most of what was mentioned on the "test" understood. Or, at least have to plans in place to get there ASAP.

There will be no more curves after 2008, eventually we have to figure this stuff out.

Happy New Year.

Posted by Dave Linthicum on January 1, 2007 07:51 AM

REAL WORLD SOA PODCAST

Listen to the latest podcast:

MP3 •

•

• Archive •

Technology White Papers

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert