UPDATE: The Road to the Service Oriented Enterprise

For the last few weeks I've been traveling the nation talking to corporations about their transition to the Service Oriented Enterprise. I've met some great people and listened to their problems.

It has been good for me to get out of the newsgroups, the blog-o-sphere and the intellectual community to go see what Joe Developer is up to. Here are some of my favorite quotes:

"Jeff, it was only a few years ago that we quit writing programs in Assembler and started writing them in COBOL."

"Development methodology? Yea, we have a development methodology - write the code real fast and put it in production."

"We are picking an EAI product to implement our service network."

Here are some other highlights:
- There was a huge gap in knowledge between architects and developers. The architects knew the buzzwords, had read the white papers and most of the developers were completely clueless on next-gen stuff. Developers were soooo busy learning new J-stuff (maven, hybernate, canoe, etc.) that they just didn't have time to worry about the WS-stuff.
- Managers and directors knew the buzzwords but didn't know how to cost justify or create a roadmap.
- People want to implement a "web services catalog" (think UDDI registry - perhaps even slimmed down).
- Most architects had heard of ESB's and were actively shopping for one.
- Many of the customers were explicit about NOT wanting to work with startups on their infrastructure. Their short list was usually: IBM, BEA and Tibco.
- The fundamentals of designing systems for use, reuse, evolve-ability and agility were missing. Developers don't need WS training, they need loose coupling training.
- The role of 'business analyst' or 'requirements analyst' seemed to be missing in many organizations. Use cases were NOT rolled into business cases.
- In large corporations, the majority of the employees had never spoken with their CIO, never seen a strategic I.T. plan (annual or otherwise) and never had the chance to talk with anyone of any influence about the fundamental problems in their organization.
- I.T. budgets are returning.
- Morale is mixed. Some are happy to have jobs others are upset about their career potential.

Conclusion
The potential for solving problems is high, but unfortunately many organizations have a huge gap between leadership and worker-bees. We need a major upgrade in 'business and I.T. alignment' before we move too far down a new paradigm shift like the Service Oriented Enterprise.

WS Questions...

I've posted a couple questions out at:
http://groups.yahoo.com/group/service-orientated-architecture/

Here's a condensed version, with some additions:
1. Should a WSDL be produced for the ultimate sender? If so, should it be stored in the registry? If not, why not?

2. If "Contract First" is considered a best practice, should it applied to ultimate senders in addition to ultimate receivers?

3. Should a WSDL editor create two WSDL's at once (one being the invocation document advertised by the sender, the other being a service-side WSDL)?

4. Imagine that you have two WSDL's: one representing the ultimate sender, the other representing the ultimate receiver. The outbound interface on WSDL #1 matches the inbound interface on WSDL #2 (an operation signature match). Should the 'component-service' composition environment visually enable a 'snap together' programming model?

5. Let's call the thing that components and services snap into the "SCB", a variation of the PCB (printed circuit board). Should the SCB dictate the flow-of-control in a proxy like fashion (like bpel)? Should the SCB act as a message router focusing on endpoint resolution?

These are important questions. As one WS-Luminary told me, "composition is the killer app". Can I be any more blunt? ;-)


-----------------------
Definitions
Ultimate Sender = the caller, the consumer, the client, etc.
Ultimate Reciever = the service, the producer, the recipient of the call, etc.
Contract First = the practice of stubbing out functional interfaces and non-functional policies prior to writing the implementation.

Compliance Oriented Architecture

RedMonk did a nice piece on the intersection of SOA and Compliance Oriented Architecture.

Good going! I agree that SOA is a good technical foundation for meeting compliance needs and that addressing compliance as an architectural requirement is an excellent idea.

Components and Connectors

I liked this statement:

The C2 architectural style is primarily concerned with high-level system composition issues, rather than particular component packaging approaches [3,5]. The building blocks of C2 architectures are components (computational elements) and connectors (interconnection and communication elements). This separation of computation from communication enables the construction of flexible, extensible, and scalable systems that can evolve both before and during runtime. This style places no restrictions on the implementation language or granularity of components and connectors, potentially allowing it to use multiple interoperability technologies for its connectors.

See: http://sunset.usc.edu/~neno/teaching/s99/NR98.pdf

It is also interesting to see C2 and REST presented as alternative architectural styles. I really like the idea of architectural description languages that are constraint based. Section 2.3 of the Web Services Architecture document is wonderful. Oddly, the other portions are out of place.