My recent posts about integration with Microsoft Exchange have reminded me how important it is to keep the pragmatism of the application of technology to solve business problems very sharply in focus. During the process of building the Microsoft Exchange integration components, I have also been involved in a couple of projects that are very enterprise-focused during my day job. The combination of these projects made me step back and think about how we build software, and I realized that during the 20-some years that I have been in this industry, there are some things that I have learned and applied that have become the cornerstones of how I approach software. Later in this article, I am going to come back to this because it is key to the importance of Enterprise Architecture. 

Enterprise Architecture

As the term "Enterprise" suggests, enterprise architects are responsible for architecture that is enterprise-wide. That is, they are responsible for looking at the entire organization and understanding how it is structured to do business, identifying the areas where the process can be improved – often by the introduction of a technology solution – and then introducing the business process improvements and technology solutions that streamline the business.

Mature enterprise architecture actually goes even further than that. In a mature organization, enterprise architects work with the business leaders to define and enhance future business strategies, define processes to meet the strategies, and then implement those processes, using technology where appropriate.

What this means is that enterprise architecture is as much about understanding business as it is about technology.

Enterprise Architecture Disciplines

As with any discipline, enterprise architecture has numerous facets. The diagram at left shows all of the disciplines that are associated with enterprise architecture and provides a visual queue for how they relate to each other.

Disciplines in blue are all predominantly business-focused, whereas those in brown are more technology-focused. The lower down the stack you go, the more technology-focused the discipline is, whereas the higher up the stack you go, the more business-focused it is.

The oddball in the stack is Research and Innovation. This is a discipline that needs to span technology and business.

There are a few important things to bear in mind about these disciplines.

First, none of them lives in isolation. They all need each other to successfully deliver value to the enterprise.

Second, none of them is more important than the other. Just because Business Architecture is at the top of the stack does not mean that business architects are more important than database architects. Rather, the stack is intended to show how these disciplines relate to each other.

Third, a lack of focus on any one of these disciplines creates a gap that makes the stack incomplete. Inevitably, the organization will compensate for the lack of focus on an element in the stack by creating a compromised design. Nowhere is this more evident than in the Data Architecture discipline. If there is no focus on data architecture, an architecture will emerge organically, almost always generated from the schemas of component applications. The result is that integration suffers. 

Lastly, every discipline in the stack is directly dependent on the discipline above it. So information architecture requires a thorough definition of the business architecture in order to produce the business intelligence that is needed. Data architecture needs a clear information architecture to provide the data that is needed for the business intelligence to be derived, and so on.

An argument could be made that enterprise architecture governance is also a part of this stack. I am not opposed to that, but I really view governance as a management function that is embedded in each of the architectural disciplines. In some organizations, that governance does need to be broken out into a separate unit.

Let's take a look now at some details of what each of these disciplines does.

Research and Innovation

Research and innovation is really the oddball in the stack, because it spans the entire enterprise architecture stack, from business architecture all the way down to specialist architectural disciplines. in fact, it goes even lower than that, but that is beyond the scope of this discussion.

Research and innovation is about understanding what is going on in all industries that are related to the enterprise, understanding advancements that are being made that could enhance the business, and finding ways of exploiting those advancements to create competitive advantage. It also includes incubating new ideas that could allow an enterprise to leap-frog its competition.

In a future article, I will spend some time talking about how the research and innovation component of the Microsoft Exchange integration project has provided this kind of competitive advantage.

Business Architecture

It is hard to understate the importance of business architecture, and I think it is really interesting that in the last 10 years, IT has felt the backlash of driving businesses to make decisions based on technology, rather than sound business principles. Leading into Y2K, two massive technology drivers were forcing businesses to invest exorbitant sums of money in projects that were little more than experiments in technology – the Y2K "bug" and the advent of internet commerce. Much of that investment returned little to no value, and today IT organizations are being forced to focus their attention on business value. Business architecture is the architectural discipline that leads this initiative.

What this means is that business architects are really focused on understanding the business, not the technology. In a mature organization, business architects (and business analysts) work very closely with business units to understand their business processes. They are responsible for analyzing how the business runs, producing the definition of the business processes, defining new processes that align with the strategic goals of the enterprise, and defining the requirements from which all technical decisions are derived. A very important part of a business architect's role is to evaluate the existing processes to reduce redundancy, streamline the process, and automate as much of it as possible. Highly skilled business architects are also able to define the key performance indicators within a line of business so that it is possible to measure the success of the business.  

Information Architecture

Information architecture is the process of understanding what information the business needs, how to go about delivering it, and ensuring that nothing is lost. As with business architects, information architects have a strong business focus. They are normally lateral thinkers who are capable of envisioning ways to transform data into actionable business intelligence. Over and above the general reporting requirements that is part of the responsibility of information architecture, the discipline also involves understanding interactions with external stakeholders such as vendors, partners, and customers and producing an information strategy that monitors and enhances these interactions.

As with the business architecture discipline, information architecture is highly business-focused with its purpose being to provide decision makers the information they need to maximize business profitability.

Data Architecture

Probably the most neglected discipline in most companies is the data architecture discipline. Many people see data architecture as a function of information architecture, and it is probably best kept as part of the information architecture discipline, but it is really the first layer in the architecture disciplines that crystallizes business concepts into technology artifacts. What I mean by that is that data architecture is all about understanding the nature of the data in an organization, what operates on it, and how it is stored.

The data architecture discipline is absolutely crucial to integration because data architecture is the custodian of the enterprise data model that defines entities and their relationships across the enterprise. It therefore affects every other discipline around it, including application architecture, infrastructure architecture, solution architecture and integration.

The data architecture discipline also owns the responsibility of defining and maintaining the canonical model that is used in a service-oriented architecture to govern data transformations between services. 

My next post will include a detailed discussion of this discipline, especially as it relates to the Microsoft Exchange integration project.

Application Architecture

Application architecture is the process of understanding how applications operate on the data that is defined by the data architecture discipline. It is also responsible for understanding integration between applications so that they are able to properly communicate with each other and provide each other any necessary data.

Application architecture is also the custodian of the library of services that are required for a service-oriented architecture and they own the definition and governance of that library.

Infrastructure Architecture

Infrastructure architecture is the process of understanding the "plumbing" that is used to support a technical solution. So, for example, in the Microsoft Exchange integration case, Microsoft Exchange is an application and the OpenEdge CRM application is an application. These two applications need to communicate with each other. One (the OpenEdge CRM application) runs on a Unix server and Microsoft Exchange runs on a separate set of Windows servers. At a lower level, the OpenEdge CRM application has an AppServer associated with it and Microsoft Exchange uses a web server and has several server processes that are associated with it. With the roll out of the Microsoft Exchange integration solution, additional Java-based services such as Apache Tomcat and Apache ActiveMQ will be added to the mix.

Infrastructure architecture is about understanding these technical components, how they relate to and communicate with each other, and where the opportunities are for optimizing these infrastructure components.

As we move closer to cloud computing, this is a discipline that requires increasingly skilled people because virtualization, high-availability, network fabrics and all of those components factor into the decisions that are being made about hosting technology solutions.

The Divide between Business and Technology

Up until this point, all the disciplines that we have discussed have been focused on the business. Most of the questions that are being asked in those disciplines are related to how the architecture can be built to drive increased revenue and reduce operating costs. Many view this point as the division between what they call Enterprise and Technical architecture. In order to ensure maximum business benefit, though, these disciplines all need to work very closely with each other in a tightly cohesive team. I, therefore, view technical architecture as a facet of enterprise architecture and prefer to view technical architects as specialist architects who have extensive knowledge of their particular discipline.

Solution Architecture

Solution architecture is the discipline that most people think of when they talk about a Software Architect. A solution architect is able to take a specific problem, identify the appropriate way to solve the problem, and turn that into a technical solution that spans numerous specialist disciplines. The key point about this discipline, though, is that it is more technically oriented than business oriented. Successful solution architects are often viewed and technical gurus, capable of solving any technical problem.

Specialty Architecture

Specialty architects are extremely valuable resources as they understand their area of specialization inside-out. Generally, specialty architects have been in their field for several years and have solved significant business problems with the technology with which they are proficient. The above diagram references several time of specialty architects.

Integration architects have a thorough understanding of integration technologies like middleware, complex event processing, and business activity monitoring. In a service-oriented architecture, this discipline is responsible for overseeing the implementation of the canonical model and all related services. 

Application-specific specialty architects focus on products like SAP where there is a high level of skill required to understand the application as a whole. The other specialty architects are also highly skilled in their particular avenues and able to advise, mentor and lead significant development efforts based on their particular technology.

While it is likely that specialty architects are exceptional programmers, the discipline itself does not requires them to write code. 

Structured Systems Analysis and Design Methodology (SSADM)

What I find really interesting is that these disciplines have really only become clearly defined in the last few years. The reason is that 20 years ago, computer systems were nowhere near as complicated as they are now. There were far less of them and they were far more monolithic.

Nevertheless, 20 years ago I attended a course on a methodology called Structured Systems Analysis and Design Methodology (SSADM). In those days, systems analysts were expected to perform the business analysis and architecture function. So they would be responsible for documenting the business processes that the business needed.

From those business processes, a systems analyst would derive a set of data entities from the connecting lines between the processes. They would flesh out those entities by reviewing the paper forms or screenshots of existing applications to understand what the data elements were that made up the application. 

Those same analysts would then create a matrix (called an Entity-Event Matrix) that contained each process in the columns across the top of the matrix and each entity in the rows down the left side. They would then mark with a C, R, U, or D any cell that was affected by either a create, read, update or delete of the entity. From this, an entity life-cycle could be produced that demonstrated the life history of an entity. 

This matrix and the life-cycle were then used to build a specification of the processes that had to be built to operate on the data. Next, a set of JAD (Joint Application Design) sessions with the user would define the set of screens that would be built to enable the user to interact with the system and the reports that would be generated from the system.

Once the design is complete, the systems analyst and a group of programmers would go off and build the application.

As I said, this was a methodology that I was taught 20 years ago, and although much of it has been augmented by additional requirements imposed by additional complexity of modern computer systems, at the core, nothing has really changed that significantly. TOGAF and Zachman, two more modern enterprise architecture methodologies, emphasize the same basic principles of enterprise architecture. Of course, it is a much more iterative process now.

Conclusion

In many enterprises, architects are expected to be proficient in more than one of these disciplines. In large enterprises, although there is an expectation that enterprise architects are proficient in more than one discipline, often their focus is narrowed considerably by the amount of work to be done.

Nonetheless, I have found that my experience with SSADM taught me many of the things about enterprise architecture that I never knew I was going to value, and now, 20 years later, I am fortunate that I am able to cover the entire stack of enterprise architecture disciplines and many of the specialty disciplines, thanks to what I learned from SSADM.

Enterprise architecture is a relatively new buzzword that is increasingly being seen to provide significant business benefit and substantial return on investment. Look for these disciplines to grow significantly over the next 5 years as IT systems become increasingly complex. 

In the upcoming weeks, I will be building on this discussion by delving into each of these disciplines in more detail. First on my list is data architecture, as it is a discipline that is very near and dear to my heart.

A couple of months back, a gentleman who has now become a friend and business partner, Jim Ford of Ford Audio-Visual, came to me and asked me if there was any way to get at all the calendar items in his sales organization's calendars with the intention of integrating it with his Progress OpenEdge CRM system. Jim is using Exchange 2007 for his e-mail and calendaring solutions.

I was aware that Microsoft had released a new API for Exchange in Exchange 2007 called Exchange Web Services (EWS), and so I said that I needed to do a little research on the API, but I was pretty sure that it was possible. Sure enough, MSDN has some documentation of the API and Microsoft is touting it as the replacement for all APIs that communicate with Exchange. Web Services – how hard can it be?

The Production Environment

In the production environment, an OpenEdge client running on a Unix server needs to initiate a WebService call to Exchange to create, update and delete appointments for sales people. These appointments will be created in the user interface for the CRM application.

Sales people then need to be able to change and delete these appointments from their Outlook clients or their Blackberry/iPhones. Any changes to the appointments need to be recorded as history updates in the CRM system, so Exchange needs to notify the OpenEdge CRM system of these changes.

So the updates to appointments need to happen from both directions and the communication is going to happen cross-platform (Unix to Windows and vice-versa).

Initial Idea

My initial plan was to create a prototype that did the two-way communication directly from OpenEdge to EWS. I just wanted to prove that it was possible. The first step was to build an OpenEdge WebServices Client that created a calendar item in the Exchange store. Unfortunately, for various reasons, this is much harder than I thought it would be.

First, the EWS WSDL is not a standard WSDL. EWS is installed as part of the Client Access Server (CAS) component of Exchange. In production, you can have multiple Mailbox Servers and the CAS has to discover which mailbox server services a client. As a result, the URL that is used to actually call EWS is different depending on which Mailbox Server hosts the mailbox. The WSDL therefore does not contain a "service" node and the OpenEdge WSDL parser cannot parse the WSDL. I tried working around that by creating a dummy WSDL with a service node inside it.

The second problem was that I ran into all kinds of problems with the complex type structure that exist in the WSDL. The types and messages live in a separate XSD file and the WSDL parser did not like some of the message definitions as they included optional types.

The last straw was that the connection to EWS is an SSL connection that, by default, wants to use NTLM authentication and I battled for hours to get this to work. I would probably have figured the problem out earlier if I had had some more clear indications from OpenEdge of exactly what the problem was, but I finally decided to go and try the connection from Java.

The Bible

Before I started on the Java example, I decided that I should probably test that I could even make this happen in .NET. Even that is no small feat. The examples that come with the Exchange SDK are about as useful as an udder on a bull, and I eventually decided to bite the bullet and look for a book on the subject.

I normally avoid Microsoft Press books because, more often than not, they simply regurgitate the standard Microsoft examples and contribute very little additional value. That is not the case with Inside Microsoft Exchange 2007 Web Services. Authors David Sterling, Benjamin Spain, Michael Mainer, Mark Taylor, and Huw Upshall have done an outstanding job of creating a book that really gets to the heart of the technology. They are all members of the Exchange development team, and it shows. The book provides enough background information that it is essential reading for anyone trying to do this stuff.

Java to EWS

Armed with my new reference, I now set about building a Java client that could create an appointment in Exchange, figuring that I could expose the Java client as a Web Service that OpenEdge could consume.

Now, before you throw your toys out your crib and tell me that that is a very expensive way to do things from a performance point of view, let me just clarify that I would have ended up going down this road eventually, anyway. Ultimately, the solution will be exposed as a service on an ESB, and that ESB is likely to be based on a JMS MOM, like Apache ActiveMQ, or SonicMQ. So this is not a wasted exercise. The reason that I need this on an ESB is that the events that flow in each direction need to be available to other services, too.

Java to EWS was not a lot easier to get working. I still had to work around the WSDL not having a "service" node issue, but Java gives you finer-grained control of the parsing of the WSDL. Moreover, in my initial implementation, I did not use JAX-WS or any other WebServices technologies like Axis. I simply used an HTTP request to the WebService to get through the issues. This made life a whole lot easier.

The SSL problem reared its ugly head again, but this time I quickly learned 2 things:

1. Exchange creates a default certificate for you when you install it. Either you have to install the certificate as a trusted certificate in the certificate store, or you have to set up a certificate authority on your Windows Server and build signed certificates. I went with the former idea and that resolved the first part of the SSL problem.
2. Exchange is installed to support only NTLM authentication, but NTLM authentication is a pain to work with from non-Microsoft technologies. You can change the settings of the EWS virtual directory on the Microsoft IIS Server that runs on the CAS to support basic and digest authentication. For testing, I set this up as basic, but I now have digest working. I will probably go back and revisit NTLM again later, but it is very hard to find any information to help with solving problems, so I may simply require digest authentication.

Once I got past these issues, creating the calendar item was actually very simple.

OpenEdge through the Java WebService

The next step was to take what I had created and expose it as a Java Web Service. I went with Glassfish V3 as the application server just to test this and in about a half hour I had the Web Service up and running and soapUI was creating appointments through the Java Web Service without any problems.

I then went back to OpenEdge and used its WSDL analyzer to analyze the WSDL. It worked really well. I then built a quick client that called the Java Web Service from OpenEdge and it worked first time.

Next Steps

Although this is now a working prototype, it is exactly that – a prototype. There are several pieces that still have to be proven:

1. I need to subscribe to change updates from Exchange.
2. I need to get to updates for all sales person mailboxes. This means I need to use Exchange Impersonation and that has a number of security risks associated with it.
3. I need to make sure these updates get through to OpenEdge efficiently which means I need a test harness that can generate several thousand appointments a minute and have them update the OpenEdge AppServer without breaking it.

Conclusion

Having said that, I am really excited and very optimistic about how this is turning out. I have learned more about Windows Server, Microsoft Exchange, Active Directory, Exchange Web Services, OpenEdge Web Services, and Java Web Services than I had ever imagined possible.

In the next few weeks I will be providing an update on where I finally ended up with this from an architectural point of view.

In a follow-up post, Ms Manes pointed out that  "SOA is a bad word. And yes, doing SOA is a good thing. (And we need to keep doing it!) But no, we do not need to come up with a new name. Emphatically not."

This morning my RSS feeds had an update from Ms Manes’ blog again. She points to an article by Dan Woods of Forbes.com and says of his article that she is "pleased to see that Dan read beyond the first paragraph, and he understands the core message of my post (i.e., ‘SOA has been disappointing and that services should be a key focus’)" and then goes on later in her post to say:

"Dan recommends an incremental approach to SOA: Just build services as you need them on a project-by-project basis, and at some point in the future you can go back and consolidate the services you’ve built and somehow derive some architectural consistency. Unfortunately, this strategy invariably leads to Just a Bunch of Web Services (JABOWS) because the future consolidation step almost never happens. The result is too many services, too many moving parts, and too many brittle connections. Systems wind up being more expensive and more fragile than ever before."

I wonder if Ms Manes realizes that she advocated exactly the same thing that Mr Woods advocated and then went on to slam the idea? In her original post she argued that the focus should shift from SOA to building services, and yet here she is arguing that just building services will result in fragile, expensive systems. Ms Manes is just flat-out contradicting herself.

Without the overall service-oriented architecture you will not get a cohesive system. So recommending building services without an overall service-oriented architecture is a bad idea… as Ms Manes suggests.

At the same time, Ms Manes does not like the term "SOA" because of the negative connotation it has garnered thanks to a lack of understanding that business need to make a significant commitment to change and there are unscrupulous individuals trying to profit from a technology buzzword. For those reasons, Ms Manes believes SOA is dead. Ms Manes, however, does not believe we should get rid of the word "SOA".

In her latest post Ms Manes makes the statement that "One of the reasons SOA ‘died’…" Just stop right there!!!

Whether you like the term SOA or not, service-oriented architecture is a critical part of Enterprise 2.0 and requires a significant investment in both the architecture and development of services. Service-orientation has to drive the way that development teams build applications today and into the future.I hate to tell you this, Ms Manes, but SOA is not dead. There are numerous organizations who are still working extremely hard on a service-oriented architecture and many more are seeing the importance of it more and more with things like mashups and social networking becoming tightly integrated into the business.

I don’t disagree that SOA requires governance, management, leadership, skills, practices and a commitment to change. But remember that change is hard and takes time. In fact, it takes more time as the organization gets larger. A weak economy has caused businesses to refocus priorities and in many cases this has meant cutting projects that are not directly contributing to the bottom line. Companies are not willing to shell out several hundred thousand on projects for which the ROI may only be seen in 5 to 10 years. For some companies, that is the amount of change that SOA requires and simply buying an ESB is not going to resolve the issues.

A service-oriented architecture does not come from the presence of an ESB. It is definitely not characterized by the availability of a bunch of services in an organization. SOA is a paradigm shift like event-driven programming was a paradigm shift and object-orientation was a paradigm shift. All of them came with their share of snake oil salesmen too and nowadays those paradigms are standard in business.

SOA is alive and well… and growing.

Now you may be sitting there reading this thinking "OK… that was back in January. Why are you still writing about it now?"

Well since then the blogosphere has been on fire with people chiming into this debate asserting that "SOA is too complicated" or "ESBs have failed" or "businesses cannot afford SOA" or some other statement along those lines, implying (sometimes directly stating) that SOA was a bad idea and that it deserves to die.

Even people like Brent Foody at Progress Software agreed with Ms Manes when he wrote about this in his post. As Progress is normally pretty good at ensuring that its own corporate blogs meet the business goals of the company and given they own Sonic Software, vendor of the Sonic ESB, it is surprising that they allowed a posting prematurely acknowledging the demise of an architecture that they promote. Add to that the fact that Mr Foody's comments contradict David Chappell's own thoughts on the matter and you can see why I am surprised. Remember, David was pretty much the architect of SonicMQ and the brains behind SonicESB.

But even those were posted way back in January. As late as last week, though (July 23rd), there was still fall-out from this post. ZapThink hosted a ZapForum entitled "Night of the Living SOA Dead" where people would get the chance to argue the whole thing out. So this story has had legs for nearly 7 months.  

When I read Ms Manes' post, I felt like the person standing on the sidewalk in a movie. The camera is focused on me and someone (SOA) steps out into the street. From the side of the screen, off-camera, a bus comes careening past and the person that stepped into the street is hit and taken completely out of camera and I'm left standing with my jaw on my knees.

Of course, if you carefully read Ms Manes' post, you have to agree with at least some of what she is saying:

• The economy cannot support SOA projects that do not provide good ROI in a fairly short period of time;
• There is nothing to be gained by SOA for the sake of SOA;
• SOA is not the hammer for every nail;
• SOA is best viewed as part of an application modernization strategy for breaking up the monolith; and
• SOA is not the silver bullet that will fix everything your organization.

Ms Manes' argument that the state of the economy would lead to the demise of SOA leaves me more than a little perplexed. Sure. Companies will cancel SOA projects that do not have significant ROI in the short or medium term in order to focus financial resources where they are most needed, but that does not spell the demise of SOA. Rather, it does what needed to be done in the first place – focuses business priorities on the highest ROI first.

Many vendors have bandied the SOA acronym around as the mechanism for selling their wares - from ESBs to high-cost consulting gigs; from application servers to expensive monitoring tools, all in the name of a service-oriented architecture. There is no doubt that a number of companies have excellent products that are intended to assist in building out your service-oriented solution, but just because you have an ESB does not mean that you have a service-oriented architecture. Neither is it true that because you have deployed several WebServices you now have a service-oriented architecture.

Ms Manes' arguments are actually not new. In fact, many of her comments very much echo the sentiments of Thomas Erl, author of "Service-Oriented Architecture – Concepts, Technology and Design".

Back in July 2005, Mr Erl contended that "the rise of the false SOA [one characterized by the idea that a set of deployed WebServices represents a service-oriented architecture] has distorted the vision of the ideal SOA. Not only is the false SOA divergent from the 'true path of service-orientation,' it reinforces SOA anti-patterns by extending and further entrenching the traditional distributed computing model to which SOA offers an alternative." Essentially, Mr Erl makes the point that unless your implementation of SOA follows a well architected strategy, you are doing nothing more than creating a more complex distributed computing system.

With the amount of money that has been thrown at SOA, business has a right to expect that the problem that SOA was intended to resolve has been resolved. The issue is that there have been too many snake oil salesmen delivering products to a site and then leaving the organization to find its own way. Sometimes, the 'snake oil salesman' actually sold a very good technology into the site with an offer of professional services to establish a competency center, but the customer failed to understand the importance of a supervised architectural change to the environment. As Mr Erl observes, "A real SOA requires real change, real foresight, and real commitment. Most of all, though, it requires guidance." – (Italics my own).

This brings me to my disagreement with Ms Manes' point of view. Ms Manes states "Successful SOA (i.e., application re-architecture) requires disruption to the status quo. SOA is not simply a matter of deploying new technology and building service interfaces to existing applications; it requires redesign of the application portfolio. And it requires a massive shift in the way IT operates." She follows this up by saying "The latest shiny new technology will not make things better. Incremental integration projects will not lead to significantly reduced costs and increased agility. If you want spectacular gains, then you need to make a spectacular commitment to change." In these statements Ms Manes' is asserting that business somehow expects an overnight change and that a successful service-oriented architecture can only come from turfing your existing architecture and replacing it with a new SOA-based solution. Not only is that not true, but it is also hopelessly unrealistic.

Yes, SOA requires a different way of thinking and paradigm shifts are not going to come overnight. And yes, deploying a new technology and building service interfaces does not constitute a service-oriented architecture, but it is an extremely important transitional step in moving a commercial environment to a more service-oriented architecture.

Ms Manes ends her post by saying "And that’s where we need to concentrate from this point forward: Services." In so doing, Ms Manes is opening us up to the same "false SOA" that got us into this mess in the first place.

Ultimately, a thorough service-oriented architecture has proper governance and standards in place across all deployed services to ensure the abstraction of the underlying components. If that governance and standardization is not in place, services are simply distributed components.

So, no. SOA is not dead. A service-oriented architecture is something that businesses definitely need to aspire to achieve. It's probably safe to say, though, that the 'snake oil' SOA days are over.