Monday, May 02, 2005

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.

Sunday, May 01, 2005

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.

Thursday, April 28, 2005

SDM - it's right.

My father bought one of the first 100 TRS-80 computers ever made and at the age of 11 I was fluent in assembler. By the time I finished high school, I could program in 14 languages. I've found other people who have similar backgrounds - and in almost every case they share a similar trait: the ability to recognize a disruptive technology.

In my career, I've made a few "early calls":
1985 - Windows 1.0
1991 - Visual Basic 1.0
1993 - PowerBuilder 2.0
1995 - Java
1997 - XML
2002 - BPEL

and now,
2005 - SDM

It's that big. It's right - and it will change our profession.

Sunday, April 24, 2005

Canned Architecture

Several things in the Agile world has always bothered me. The one I'd like to point out today is the concept known as BDUF. The summary of BDUF is:
"The term BigDesignUpFront is commonly used to describe methods of software development where a "big" design is created before coding and testing takes place. Several ExtremeProgramming (XP) advocates have said that such "big" designs are not necessary, and that most design should occur throughout the development process."


Over the years I've noticed that the closer one is to the code, the less they tend to distinguish between architecture and design. "Code Intensive" people tend to be bottom up guys - they start with code, refactor to a new design - rewrite, refactor, repeat. Call me old fashioned, but I firmly believe in the use of enterprise reference models, template architectures, application blocks, architecture & design patterns and candidate architectures. This clearly puts me in the bucket of "Big Architecture Up Front" - and I'm proud of it.

In the last 8 years at MomentumSI, I've had the chance to see hundreds of projects across our clients. And the one thing that has always amazed me is the reusability of architecture and design elements. Sure, the platforms change - new elements are added - the functional domain is different, but for the most part the basic architecture and design is usually about 80% reusable.

To clarify my position, I'm really a "Canned Architecture Up Front" kind-of-guy. In working with architects, I've noticed an interesting behavioral pattern. Application architects realize that when their architecture is "finished" they're probably going to have to do "design work" or God help them, "coding". For this reason, they tend to re-invent architectures and make them drag on for long periods of time. This is bad.

We are in interesting times. I'm predicting that the "Big Custom Architecture Each Time" guys are going to find themselves in a pinch. Microsoft (and others) are moving us into a world of "drag & drop architecture".

Microsoft's decision to embrace an Architecture Description Language (SDM - the Systems Definition Model) has the potential to overhaul the profession. SDM will likely spark a renewed interest in creating digital descriptions of our architecture, leading to an ADL competition and overall advancement of the discipline.

Digitized architecture also has a greater potential for enabling architectural refactoring, automated vendor sourcing, self-reflecting documentation and automated environment provisioning. But the thing that gets me excited is significant reduction of 'architecture time' by using enterprise-grade, off-the-shelf, canned, distributed architectures.

Friday, April 15, 2005

SOA: Business Impact Strategy

A major shift has been occurring over the last few months in the SOA adoption curve. "Business people" are now being tasked to understand the strategic business impact of SOA/Web Services in their organization. This is a significant deviation from the last set of strategy calls around "strategic SOA implementation".

Many organizations have completed the first stage of maturity. That is, they have a SOA strategy in place, a SOA methodology, a reference model, candidate architectures and core infrastructure components (registry, repository, SOAP routers & firewalls, pipe & filter mediation, service bus, SOA EII, metadata compliance, testing suites, SOAP-to-Legacy adaptors, specialized "service servers", etc.) Typically, a core team has been trained but a larger training plan is available. Again - this is in "leading organizations" - not the majority!

These leading I.T. organizations are now giving the business units the go-forward nod, indicating that they have their act together and passing the baton to the business units to make the next move. Much like we saw in late 90's around the Web, business managers are looking at the capabilities of the technology, studying the disruptions and applying it to their domain.

I'm starting to see SOA patterns of disruption emerge - but it is still early. Very exciting - more to come...