>SOA – Does the Emperor Have Clothes?

>

Architecture and Governance Magazine, Volume 3 Issue 3, reports that one of the Top 10 Challenges in Enterprise Architecture is “Getting Ready for Service-Oriented Architecture (SOA)”.

– Why is SOA proving to be such a challenge?

The article reports that “most architects have not done much of either substance or significance in this area.” Further, “most of what enterprise architects have addressed in this space concerns aligning IT with the business and governance”—and this is something that EA has been doing all along anyway.

– So what has SOA changed?

“What has changed is the promise of abstracting services that can be reused.”

However, some have questioned SOA:

  1. Is SOA “just a revival of modular programming (1970s), event-oriented design (1980s), or interface/component-based design (1990s)”?
  2. Is SOA “just another term for Web Services”?
  3. Is SOA “merely an obvious evolution of currently well-deployed architecture (open interfaces, etc.)”? (Wikipedia)

Others have questioned if SOA and EA are even distinct disciplines?

“So, has SOA in fact evolved into EA? A to question to which the answer is yes and no.” The author continues, “essentially there are three evolutionary paths:

  1. EA is absorbed by SOA
  2. SOA is absorbed by EA
  3. EA / SOA merge into a new concept”

Finally, the authors propose #3 merging EA and SOA as follows:

“SOA-A+EA = SOEA”

With the conclusion that “in order to create this holistic view EA and SOA must not be seen as separate disciplines, but to see the two as one will bring changes on such a scale that we are now talking about SOEA Service Oriented Enterprise Architecture.” (Journal of Enterprise Architecture, August 2007, Rasmus Knippel and Bo Skytte)

While the authors apparently seems to think SOA is important (although they call it “increasingly more abstract”), the relationship to EA is changing and unclear—Not sure this idea about SOEA is helpful at this juncture!

– How helpful to SOA development is the guidance from the Federal Enterprise Architecture (FEA), Service Reference Model (SRM), which talks about services and capabilities?

Not very! The SRM is supposed to “provide a high-level view of the services and capabilities that support enterprise and organizational process and applications.” (FEA, SRM). However, the service domains, service types, and capabilities listed in the FEA SRM are quite muddy, at best. Here is an example:

  • The domain of Process Automation is defined as “the set of capabilities that support the automation of process” [hasn’t every 5th grader been taught not to define a term with the same term?]
  • And it continues “and management that assists in effectively managing the business” [well that is a pretty broad definition— can’t all services assist in effectively managing the business?].
  • Then after the definition, you’re expecting some pretty extensive process automation services, but the SRM lists just 2 components:
  1. Tracking and Workflow (which includes capabilities like case management [what’s that doing here?] and conflict resolution [isn’t that a leadership skill set?])
  2. Routing and Scheduling, which includes just Inbound and Outbound Correspondence Management [so where the scheduling piece like calendaring or time management that one normally associates with scheduling and how does the routing as in Routing and Scheduling reflect the routing inherent in Tracking and Workflow category above—seems like some category overlap]

I’ll let you look at the SRM yourself to see evaluate the clarity of the other categories, but they are pretty much the same. Ok, I can’t resist, here’s one more:

  • The domain called Business Management Services, after the domain of Process Automation, actually has a service type in it called management of process {why isn’t this in the process automation domain?].
  • The other service types in this domain include Organizational Management [that includes workgroup/groupware and network management, huh?]
  • And Investment Management [ok]
  • And Supply Chain Management [which includes things like procurement, Warehousing, and Inventory Management— so why isn’t this part of back office services, like Finance, Human Capital, and Asset/Material Management?]

If this looks confusing, you’ve got my point, it’s because the FEA SRM is confusing.

– So what’s an enterprise architect to do?

Architecture and Governance Magazine says, enterprise architects need to take back the high ground here—and that must be done in 2007…today’s enterprise architect must re-engage with all the principals in the enterprise by making a case for seeing service and technology architectures as one.”— this is good advice, I suppose, but also more than a little vague!

I’ve seen a bunch of presentations (including a recent one from Department of Education) where EA has tied IT services (pretty much their IT portfolio) to requested business capabilities—again it seems pretty much like what EA is or should have been doing all along, aligning business and technology investments with a focus on reducing gaps, redundancies, and inefficiencies.

I’ve seen other people including some prominent computer and consulting vendors present this topic as well, and aside from pushing there wares, have seen them fall all over themselves tying to define and explain SOA. Honestly, it was pathetic!

Finally, I have seen one impressive implementation at a government agency, and it did actually have savings associated with it, but the application was done a few years back, was relatively small, and there has been little to no movement on further SOA development since (except for the purchase of an enterprise service bus) even though there is a mandate in this agency to implement SOA.

In fact, at a recent meeting with the business side from operations, the presenters said that they were going to spend oodles of money rewriting one (if not the) major operational application for the agency (over 1.2 million lines of code and growing) to make it .NET compliant. I asked the business if they were going to take this opportunity to do this using SOA, and they said no, they just want the same functionality as before!

So in the end, if the business doesn’t want it and the vendors and consultants can’t explain it, the final question with SOA is does the emperor really have clothes?

>SOA Best Practices

>I came across these Service-Oriented Architecture (SOA) best practices and thought they aligned well with User-centric EA and were worth sharing:

(adapted from Naval Post Graduate School, Monterey, CA, Masters Thesis—SOA for Coast Guard Command and Control by Dash and Creigh, March 2007 — approved for public release):

  • Know when to use services – Explicitly define the extent to which we will and will not use services; services are selected with intent and do not randomly spring up.
  • Think big, start small – This allows us to validate the architecture, while giving the organization value, realized as usable services.
  • Build on what you have – Reuse legacy application functionality and data wherever possible.
  • Use SOA to streamline business processes – SOA is an inherently flexible and interoperable model for hosting application functionality; this provides an opportunity to rethink and improve business processes.
  • Incorporate standards – Use industry web service standards for navigation, application logic, integration, data stores, and enterprise infrastructure.
  • Build around a security model – Functional design needs to be built around security, and not vice versa (security cannot be added as an afterthought).
  • Design with quality in mind – Quality must be designed into the product, and not inspected into it.
  • Organize development resources – Group development team around logical business tasks, and not around technologies.
  • Train developers – Ensure designers and developers have the skills to implement SOA properly.

Basic definitions:

SOA is a software design methodology that uses loosely coupled services to perform business functions and processes.

A service is an implementation of a well-defined piece of business functionality, with a published interface that is discoverable and can be used by service consumers when building different applications and business processes.

In general, I think SOA is a great fit with User-centric EA, because the focus is on providing functional business services to the end-user, as opposed to developing monolithic, stove-piped, and redundant applications. The end-user should not have to use countless non-integrated applications systems (or even computers) to get their information, but rather the information should be technically transparent and readily accessible based on their business requirements.

>Is SOA like Legos?

>A “service” is a repeatable business task. In Service Oriented Architecture (SOA), applications are built by assembling shared, reusable, modular services into automated business processes.

In SOA, applications development shifts from technology-driven with a focus on functions and features to business-driven with a focus on business processes and services.

SOA aligns well with user-centric EA where business is the driver for technology, rather than technology for its own sake.

In the Wall Street Journal (July 30, 2007), Meg McCarthy, the CIO of Aetna, compares SOA with Legos: With Legos, we have distinct pieces that can be joined and formed into a functional object and then can be taken apart and put together again in a different way, for another use. Similarly, in SOA, we have loosely coupled services linked for use in discrete tasks, and which can then be linked in alternate ways and reused for other tasks.

In SOA independent, interoperable software can be searched, discovered, and exchanged/shared. Thus, integration is achieved by invoking service calls for necessary information and functionality.

One example where we can benefit from integration and sharing is in government in today’s post 9-11 world, where inter- and intra-agency information sharing is vital for law enforcement and defense readiness.

SOA leverages modularity and component reuse to achieve a more agile IT environment that can more efficiently automate business processes and integrate our silos of people, process, and technology.

Have you seen any examples of SOA in action?