Service Oriented Architecture

SOA - PHASE III

Several of my buds have been giving me a hard time. They're claiming that I've checked out of the SOA world. And as an emerging tech. guy, I'll agree.

You see, from my vantage point - SOA & Web Services have already crossed the 'value' threshold and are ready for adoption (Gartner is wrong.) Dare I say that WS is no longing 'emerging'. We have now entered phase III.

Phase I was basically 'protocol oriented' - with a focus on the WS-I Basic Profile (SOAP, WSDL, UDDI, XML Schema). Phase II was the WS-* stack (the aspect oriented protocols).

Phase III is about the using the darn things. Whacky, eh? You see, I talk with hundreds of companies about their utilization of web services. In most cases they tell me this:
1. We connect fat .Net clients to Java application servers (and use soap in between)
2. We connect to some ASP (like Amazon, SF.com, etc.)
3. We front ended some legacy system with services.
The same companies will brag about their rich utilization of UDDI, Fabric, ESB, etc.

However, when I ask about SOA from a reference architecture perspective, I mostly get blank stares. Then, I go to the white board, hand them the marker and say, "draw your architecture and show me where you use services." And in almost every occassion they draw an application architecture which is usually a 3+N (the usual 3 tiers plus roughly N external services - pick your favorite - LDAP, EII, orchestration, etc.)

So after seeing the same thing at several different companies you begin to realize that the world is landing on patterns of usage (and yes, 3+N is the most common). But rather than calling these 'service patterns' or something like that, they are really just architectural patterns (that use services).

Full Circle.
It's true - I'm less interested in watching protocol geeks fight in OASIS about non-sensical issues. We're finally here. We're finally at a point where we can use this stuff to create business value. That said - phase III is all about facilitating the adoption. And yes - expect to see pre-canned architectures that use SOA. But beware - the shift is heading back to 'architecture as a whole' and reviewing the place for SOA / WS in our upgraded world. You see SOA Phase III is really about putting cleaning up our distributed architectures and applying SOA appropriately.

Architecture Change Request (ACR)

There are a number of studies that discuss the impact of failing to adequately express system specifications. Oddly, most of the studies focus on the 'functional' side of the equation emphasizing the Use Cases or similar requirements document. As more and more of our work efforts are being moved to assembly line creation (outsourcing, off-shoring, remote development), it is becoming much more important to clearly articulate system specifications and the change requests.

I've witnessed teams go through great pains to version control the least important documents in the system. Source code, JavaDocs or test cases will be meticulously controlled, while the over-arching architectural documents will often go unattended. When they are versioned, they are usually treated as a BLOB, with no ability to perform a "Diff" or to maintain an automated digital log of the changes.

As organizations begin to adopt digital described reference architectures and use those elements to digitally describe their candidate architectures, they will find the ability to perform the 'diffs' and to manage change at an acceptable level.

Suddenly, we begin to see our architectural process looking much more like traditional hard-goods engineering process:

The Architectural Change Request (ACR) enables a software development team to track the changes to one of the most important elements in the SDLC, the architecture. Keep in mind, when architectural changes are made the impact (time / money), is usually significant. I firmly believe that the ACR/ACO process will encourage application architects to think and plan their architecture out more thoroughly at the initial stages leading to less rework after the project is initiated.

ADL, IDL & EDL

There are several different ways to review elements in an architecture.

1. You can look at the "interfaces" to identify the entry and exit points. Obviously, this is a big part of what web services are all about with WSDL as an "Interface Definition Language" or IDL.

2. You can look at the "engine" that provides the base infrastructure: "It's a database! It's a Rules Engine!", etc. Or more precisely, "It's an Oracle Version X database, with clustering". This is the "Architecture Definition Language" or ADL.

3. In addition, you can look at the mechanism that is used to "extend" the "engine" which provides the "interfaces". In an orchestration engine, the extension language might be "BPEL", in a presentation engine, the extension language might be "JSP". Once an EDL is identified, you can begin to look at the capabilities of the extension mechanisms (language features, libraries, etc.). Unfortunately the industry remains very immature in this area. However, I am confident that as the industry begins to understand the basics of a "language to create/describe languages" the art will quickly advance.

The software community is making progress in describing the systems we build. Our meta-descriptions of our building blocks and finished systems is a huge advancement toward the vision of the "software factory", "software IC", or which ever metaphor you prefer.


-------------------------------------------
INSIDE, OUTSIDE, UNDERNEATH & ALL TOGETHER!

Web services & SOA make people think about architecture from the "OUTSIDE" - that is, the external interfaces. The "EDL" allows you to evaluate it from the "INSIDE" - or how you build that which is exposed. The ADL facilitates "UNDERNEATH & ALL TOGETHER".

Although one of the primary benefits of SOA is to abstract the consumer from the architectural elements and extension mechanisms, this doesn’t mean that the architect that is creating the solution can avoid the issue. I firmly believe that the opposite is true. SOA architects must apply equal attention to these concerns as they do to their uniform interfaces, mediation strategies or WS-catalog taxonomy.

----
Note: I'm using the term EDL to describe the capabilities of a DSL or a general purpose programming language.

Comments

[Your favorite Executive!]

I need to speak with you about all this....call me when you have a moment? You have my number! Thx.