SOA Posers - Move Over

I've noticed that the chasm is growing between the people who talk about SOA and the people who do SOA.

This is great news. For years it was just annoying evangelists. Now, the discussion has moved to the real questions. The troops are involved and they need to know how to do it. In many organizations this shift has already happened.

The media and sellers needs to catch up. The array of conferences and WebEx's on "Funding SOA" or "What is SOA?" need to come to an end. POSERS GET OUT OF THE WAY. It is time for the architects, designers, programmers and testers to actually DO IT.

SOA: Are you Hot or Not?

In the world of SOA, here is my view of the Hot or Not:

Discussing REST style services [NOT]
Building REST style services [HOT]

Debating the merits of UDDI [NOT]
Building out your service taxonomy [HOT]

I.T. doing SOA without business alignment [NOT]
Business driven SOA [HOT]

Implementing proprietary mediation tools [NOT]
Implementing standards based, federated mediation tools [HOT]

Designing one-off WSDL's [NOT]
Performing Service Oriented Information Engineering [HOT]

Debating the definition of SOA [NOT]
Creating a strategy and plan to take advantage of SOA [HOT]

Forcing last-gen object oriented methods on a SOA world [NOT]
Updating the SDLC to take advantage of SOA [HOT]

Web 2.0 as a means to create community [NOT]
Web 2.0 as SOA composition strategy [HOT]

SOA product company evangelists [NOT]
War stories from SOA trench

Blogging about SOA [NOT]
Doing SOA [HOT]

Concern Oriented Architecture

As I look at various SOA efforts in large enterprises, I've begun to realize that their technical issues have little to do with the primary SOA patterns (client-intermediary-service, publish-discover-invoke) or styles (ubiquitous Web service connectors at the edge, etc.) Instead, the time consuming (and often expensive) efforts have to do with old fashion separation of concerns. Let's call this Concern Oriented Architecture or COA for short.

I'll temporarily define COA as the emerging discipline of separating the technical concerns and identifying remedies to those concerns in the form of engines, components, domain specific languages and other repeatable solutions. COA focuses on the technical domains (presentation, data, business logic, etc.), identifying where they are divided and how they are recombined.

As an example, one enterprise I recently visited with had the following initiatives listed as part of their SOA program:
- Create a virtual data layer across all enterprise data sources
- Break out all process logic into a new layer
- Verify that integration logic doesn't exist inside of applications
- (more...)

The concepts of separating presentation logic from business logic or business logic from data logic is well known. However, more and more emphasis is now being placed on the separation of process logic and integration logic from the aforementioned elements. The science of separation of concerns is continuing to evolve. This is good stuff, but is it part of an SOA program?

The SOA efforts that I see often have more to do with COA than they have to do with SOA. Obviously, this is due to the attention and funding that SOA initiatives are receiving. I'm ok with mixing the dollars but what is clear to me is that many of these organizations aren't even aware that they're doing this. They just think it's all SOA.

And of course there's a reason why brilliant enterprise architects are taking SOA dollars and spending them on COA initiatives. They realize that the ROI of SOA is multiplied when it is combined with COA. So where do I land on all of this? I guess my bottom line is that the analysts, press and other influencers need to do a better job of separating these efforts (our own little separation of concerns). SOA and COA need to be managed as two different endeavors that have points of intersection. Failures in COA shouldn't be attributed to SOA or vice-versa, nor should successes.

The Four Buckets of SOA Adoption

I realize that it has been a while since I've posted (as many people have reminded me), however the lack of postings is indicative of the activity in the SOA space. Bottom line is we've been busy. In the past we were busy *thinking* about SOA or *preaching* about SOA - today we're busy *delivering* SOA. And it has been busy, on the consulting side we've picked up a ton of new clients and on the training side we'll have trained over 1,000 architects & managers this year on SOA.

However, I'm noticing something really interesting about SOA adoption. You can put the adopters in 4 buckets:
1. Companies that don't do SOA and have no intention of doing it
2. Companies that don't do SOA but keep talking about it and have mastered the blame game
3. Companies that do SOA, but poorly
4. Companies that do SOA and reap huge benefits

Bucket #1
Bucker #1 companies are often busy with compliance, security, BI or other important initiatives. They had the common sense to not do SOA half-assed and have merely delayed the program.

Bucket #2
I recently attended an architects meeting of a certain industry. I witnessed 40 chief architects patting each other on the back about their lack of understanding around SOA. Only 1 in the group had done a roadmap, created a governance program and was demonstrating real results. The others made me want to puke; not because they were Bucket #1 people, but because they were bucket #2. I heard crap like, "SOA is just EAI - and we're already doing that..." - WHAT? What are you talking about?? I wanted to slap them. Honest to God. I witnessed the single biggest threat to SOA - incompetent, lazy, American, corporate architects whose skills were so dated they should go back to their 3270 terminals and program in REXX. I suddenly felt sorry for the CIO.

Bucket #3
These are the guys who have SOA programs, spend money and don't get anywhere. The problem here is almost always the same. Bucket #3 organizations have a whip-smart EA team who can rattle off every WS-* protocol (and usually do). The problem is that they live in EA land and have no ability to get application architects, developers, etc. on board. So what do they do? The EA's just keep marching blindly to the SOA drum. They act like their piece of crap SOA reference models justify their existence. They fail to actually 'realize' the models so when a line architect says, "Were thinking about doing this project using a service oriented style. You guys have been working on SOA for a couple of years; what do you have that our project can leverage?" The EA then hands them a completely non-actionable PowerPoint with a bunch of SOA diagrams that they modified from OASIS (which sucked in the first place). The recipient of this information looks at them with disgust, walks back to his project team and reports, "The jokers in EA still don't have anything we can use."

Bucket #4
Bucket #4 is the really interesting one. They succeed. The question is how? I've scratched a bald spot on my head and think I've got some answers. Here are the characteristics:
1. They have a single person ultimately responsible for SOA who leads a larger steering committee. This group also attacks organizational and process changes.
2. They created a roadmap with realistic deadlines.
3. They have an EA group where all of the members understand SOA and understand the practical needs of the application architects with regard to SOA.
4. The Application Portfolio Governance group has created a "SOA work stream" and selected new applications are sent down an SOA path.
5. The downstream teams (project managers, analysts, app. architects, designers, coders & testers) have all been trained in SOA.

Overall, I'm having a blast. As you can imagine I'm trying to focus my time on the winners. On occasion I'll take the time to let losers know that they're on a losing path, but that usually doesn't have much effect.

Tim O'Reilly Kills Web 2.0(sm)

In case you missed - The O'Reilly team and CMP wants to own the term "Web 2.0". This means one of two things:

1. Tim will return from vacation and shit in his drawers when he learns of the controversy

or

2. Tim will stand by his team and the term Web 2.0 will die.

All that I ask is that someone take a picture of Tim right after he finds out about the controversy and post it.

:-)

WiPro to compete with BPM ISV's

WiPro, an offshore consulting company, has decided to also write commercial grade BPM software and compete with their partners.

"Flow-briX is a complete BPM framework available in both J2EE and.NET platforms. With its unique customizability approach, we have been instrumental in offering best-in-class BPM /Workflow solutions to diversified market segments starting from Banking to Telecom, Media, Health Care and so on."

http://www.wipro.com/webpages/itservices/flowbrix/index.htm

Traditionally, this is a really bad move - I don't expect anything to be different this time.

SOA Testing

Recently, we've been working on our SOA testing methodology. As many of you know, testing becomes more complicated in any environment that has lots of shared resources (like SOA) and where they resources may be changed/versioned.

I recently had an interaction with Wayne Ariola at Parasoft, where he offered the following advice:

The key points from my point of view:

1) From a quality point of view the test driven process requires a SOA Aware testing framework. This means that the framework must be aware of the intermediary rich environment as well as the distributed nature elements required for the overall business process.

2) As the title of the presentation suggests, the onus of quality resides with development. Ensuring that new versions conform to published interfaces cannot be a QA function - in fact development must take an additional step to understand the impact of the change versus the regression suites as well as the overall business process. This business service orientation and the iteration/evolution of services will not be as convenient for QA to test as they are used to in an application centric environment.

3) Connection to the code. This is the big bang! Development must not only ensure that the service version is robust but must also tie the message layer changes to suite of code level regression tests.

The Parasoft SOA Quality Solution is built on an SOA Aware test framework that allows the user to exercise the message layer for security, reliability, performance and compliance as well as drive code level component tests from the message layer by automatically creating Junit test cases.

This got me thinking - what are the Golden Rules of SOA testing? Well, I think I've got my list which I intend to share at the Infoworld SOA event next week. Should be fun!

The SOA Hype Cycle

There have been a series of articles recently either bashing SOA or identifying that it has hit "rock bottom". Most of the people who take the time to write this are actually pretty big fans of SOA. Here's my take - analyst, press and vendors all believe in the hype cycle and many of them believe in 'self-fulfilling prophecies'. I am of the opinion that certain individuals are attempting to prematurely force the 'trough of disillusionment'. The thinking is that if they can declare the bottom of the trough then we can move on to the 'slope of enlightenment'. We can't force the hype cycle - up or down. It will happen on its own.

IMHO, we are still early in the cycle - very early. We're no where near hitting the bottom. Prepare for more smack talk - more crapping on SOA, especially from vendors who don't have products to meet the market or enterprises who were too stupid to figure it out.

I am predicting that after rock bottom is hit, the uplift will be much quicker than most. The reason is simple: SOA has a network effect. When the service network hits critical mass the value of the network is too high to ignore. Most organizations aren't there yet - they have 10 to 50 services (and 11-51 clients). The reuse numbers will stink for some time. Like a network - you'll know when it hits critical mass - when it's too big to ignore.

If you're interested in the actual hype/activity curve, check out:
http://www.google.com/trends?q=soa

SOA Software Acquires Blue Titan

Yesterday, SOA Software announced the acquisition of Blue Titan, a provider of service networking infrastructure.

First, I'd like to congratulate Frank Martinez (aka, "Slim"). I'd also like to congratulate the people over at SOA Software for seeing and acting on this opportunity. Those who have worked with Blue Titan over the years realize that they have a multi-part value proposition: 1. The value of their current product suite, 2. The value of their vision. SOA Software acquired both product and vision.

The on-going consolidation in this market is good for everyone. We now have fewer vendors with better product suites enabling customers to buy integrated solutions. What remains unclear is who the big winners in the space will be; who will be the Mercator of the space? Who will be the Tibco?

SOA Software has assembled a set of product technologies that will enable them to compete on the multi-part RFP's that are floating around. However, their suite of tools now has overlap with many of the pure play vendors (SOA Mainframe Enablement, SOA Security Devices, SOA Mediation, SOA Monitoring, etc.) Recently, the game for small companies has been one of 'partnering in the ecosystem'. Guys like Systinet, Actional, Parasoft and GT Software have shown their ability to pull together to promote their individual and collective causes. However, the rapid consolidation is diminishing the ability for the small companies to "eco-partner" due to their new parent companies having overlap in their portfolio (Mercury, Progress, BEA, etc.) We are close to reaching the point where *enough* of the SOA mass has moved from pure play to conglomerate. When this happens the eco-partner system falls apart due to lack of critical mass and value proposition. This sets the stage for phase 2 of the battle - the battle of the conglomerates.

With the acquisition of Blue Titan, SOA Software may have bought some industrial strength software - but let's get real, what they really bought was a mean general to fight the real war.

*-First Development

Just yesterday I was having a conversation with a developer about ‘contract first’ development. The individual was heading down the path of creating a contract prior to writing the code, as he had been instructed. But as a .Net developer, he interpreted this request as creating a ‘.Net contract’, not a ‘WSDL contract’. Naturally, I let this person know that I was interested in a ‘WSDL First Contract’, not a ‘Microsoft First Contract’. And as you might expect, the developer told me how there was no need to go ‘WSDL First’ because if he went ‘Microsoft First’, he could then generate a WSDL. As if I hadn’t heard that one before…

And once again, I had the same-ole discussion about how in SOA we would be creating interfaces completely separate from implementation – often with different groups of people – in different parts of the world – leveraging different reusable message components that would be related back to services front-ending multiple implementation platforms. He got it. ‘Microsoft First’ won’t work in an enterprise setting.

This discussion prompted me to ask some of our consultants if they were having good results with ‘WSDL First’ and the responses were positive. However, one consultant communicated that he has been pushing this concept into the requirements gathering phase. He called it, ‘Spreadsheet First’. Most I.T. Business Analysts will not be comfortable with creating WSDL’s and we continue to have an ‘analysis impedance mismatch’ between ‘legacy, silo-oriented Use Cases’ and ‘client cases / service cases’. His solution was to use a simple spreadsheet to layout the operations, messages and constraints. He would then use the spreadsheet as input in design phase, where he’d bundle the operations into port types and services and translate the field types.

One of the things I really like about SOA is having the service as unit of work. A service is right-sized for requirements gathering and specification. It is also right-sized for ‘Test Driven SOA’, but we’ll save that for another day…

Is Ruby Ready for the Enterprise?

The team at MomentumSI asks the question, "Is Ruby Ready for the Enterprise?"

http://www.momentumsi.com/about/accessarchive.html

You're so Enterprise...

The discussion of 'enterprise grade' and 'web grade' has been on the mind of the blogging community. David Heinemeier Hansson, with the recent Ruby on Rails success on his resume, recently branded an EA, "Boy, is James McGovern enterprise or what!" - let's be clear, this was meant as an insult.

He goes on to say, "Thus, allow me to make this perfectly clear: I would be as happy as a clam never to write a single line of software that guys like James McGovern found worthy of The Enterprise."

Recently, I asked some EA's to comment on this line of thinking. Putting the immature insults aside, were there valid points to be taken away?

Here is what I heard:
1. First, we can't just lump RSS, REST, RoR into the same bucket - each technology must be evaluated independently.

2. RSS can be viewed as an overlay network and has already proven to scale to the needs of the largest enterprises in the world. However, groups like MS have identified shortcomings and made feature extensions. This pattern will likely continue.

3. REST, as the principle foundation of the Web, has proven that it too can scale - but the areas where it has proven to scale the best are related to the movement of unstructured HTML documents using a constrained set of verbs. Others will note the success of RESTian API's in leading Web companies like Amazon. Most EA's were quick to acknowledge that the WS-stack is fat and that the lack of ubiquitous deployment was creating a larger than usual demand for simple RESTian style development. The delay of Microsoft Vista didn't help. EA's remain concerned that the lack of published resolutions to the non-functional concerns (security, reliability, transactional integrity) for RESTian projects will lead to either one-off implementations across the global enterprise leading to a deferred mediation problem, or alternatively might lead to a set of RESTian specifications that closely resembled the WS-specs, as they both attempted to satisfy the same use cases. The conclusions was that RESTian principles will make significant waves in the enterprise because of the solid foundation and ability to add more 'enterprise crap' on it if they need to.

4. Ruby on Rails - Generally speaking most of the EA's I've spoken with understood the power to quickly create web apps with RoR. One was quick to note, "if time to market was my primary concern, we'd use Cold Fusion, rarely is that the case." It was clear that many EA's were uneasy talking about RoR; they lacked data and were turned off by the comments that David Heinemeier Hansson had made, suggesting that Ruby was definitely interesting but were unsure if the RoR team was aware of the political nature of the enterprise - and the need to satisfy unique requirements. Most EA's were interested in finding a place to do 'departmental RoR' and kicking the tires. They were also interested in the long term potential of Ruby, RoR aside.

---- Part II
In regard to the comment that Dare had made, "If you are building distributed applications for your business, you really need to ask yourself what is so complex about the problems that you have to solve that makes it require more complex solutions than those that are working on a global scale on the World Wide Web today." I tried to have a conversation with several architects on this subject and we immediately ran into a problem. We were trying to compare and contrast a typical enterprise application with one like Microsoft Live. Not knowing the MS Live architecture we attempted to 'best guess' what it might look like:

• An advanced presentation layer, probably with an advance portal mechanism
  
• Some kind of mechanism to facilitate internationalization
  
• A highly scalable 'logic layer'
  
• A responsive data store (cached, but probably not transactional)
  
• A traditional row of web servers / maybe Akamai thing thrown in
  
• Some sort of user authentication / access control mechanism
  
• A load balancing mechanism
  
• Some kind of federated token mechanism to other MS properties
  
• An outward facing API
  
• Some information was syndicated via RSS
  
• The bulk of the code was done is some OO language like Java or C#
  
• Modularity and encapsulation was encouraged; loose coupling when appropriate
  
• Some kind of systems management and monitoring
  
• Assuming that we are capturing any sensitive information, an on the wire encryption mechanism
  
• We guessed that many of the technologies that the team used were dictated to them: Let's just say they didn't use Java and BEA AquaLogic.
  
• We also guessed that some of the typical stuff didn't make their requirements list (regulatory & compliance issues, interfacing with CICS, TPF, etc., interfacing with batch systems, interfacing with CORBA or DCE, hot swapping business rules, guaranteed SLA's, ability to monitor state of a business process, etc.)
  

At the end of the day - we were scratching our heads. We DON'T know the MS Live architecture - but we've got a pretty good guess on what it looks like - and ya know what? According to our mocked up version, it looked like all of our 'Enterprise Crap'.

So, in response to Dare's question of what is so much more complex about 'enterprise' over 'web', our response was "not much, the usual compliance and legacy stuff". However, we now pose a new question to Dare:
What is so much more simple about your architecture than ours?

My Enterprise Makes Your Silly Product Look Like A Grain of Sand

Dare Obasanjo, a Microsoft engineer recently posted the following comment:

The funny thing about a lot of the people who claim to be 'Enterprise Architects' is that I've come to realize that they tend to seek complex solutions to relatively simple problems. How else do you explain the fact that web sites that serve millions of people a day and do billions of dollars in business a year like Amazon and Yahoo are using scripting languages like PHP and approaches based on REST to solve the problem of building distributed applications while you see these 'enterprise architect' telling us that you need complex WS-* technologies and expensive toolkits to build distributed applications for your business which has less issues to deal with than the Amazons and Yahoos of this world?

Dare goes on to say:

I was chatting with Dion Hinchcliffe at the Microsoft SPARK workshop this weekend and I asked him who the audience was for his blog on Web 2.0. He mentioned that he gets thousands of readers who are enterprise developers working for government agencies and businesses who see all the success that Web companies are having with simple technologies like RSS and RESTful web services while they have difficulty implementing SOAs in their enterprises for a smaller audience than these web sites. The lesson here is that all this complexity being pushed by so-called enterprise architects, software vendors and big 5 consulting companies is bullshit. If you are building distributed applications for your business, you really need to ask yourself what is so complex about the problems that you have to solve that makes it require more complex solutions than those that are working on a global scale on the World Wide Web today.

I guess that this gets to my point. Most people who have never seen a large enterprise architecture have no concept of what it is. I'm not trying to imply that Dare is one of them, but stating the RSS and REST are cures to enterprise grade problems seems a bit myopic. So, to Dare's point - why is it more complex to do 'enterprise grade' over 'web grade'? This is the million dollar (or perhaps billion dollar) question.

Of course I have my views, but what are yours? Send me your thoughts jschneider-at-momentumsi.com and I'll recompile for publishing. My gut tells me that there is a pretty good argument to be had here - if Dare is right, I want to be the first to advise my customers. If he's wrong, well - I want to advise my customer of that too!

The Web is the Application

I was playing with Google Finance:
http://www.google.com/finance?q=WEBM and realized that the what used to be a static html page was now a highly interactive application. Of course, I am referencing all of the AJAX functionality that has been added. In many of our current AJAX apps, the focus has been to convert classic applications like email, word processing and spreadsheets into Web 2.0 apps.

The conversion of 'traditional' web pages to interactive apps deserves special attention. This is the science of blending information based on context, degrees of separation and providing the ability to quickly pivot the view. It seems as though there is a point where a web page is no longer really a web page but rather an contextually bound application. The art of blending information, informational views, navigation and functionality will likely be a critical talent of the next gen application developer.

Redneck SOA

I just found an old post of mine (almost four years ago):

http://schneider.blogspot.com/2002_12_01_schneider_archive.html#90283350

An Enterprise View of Application Architecture

Just something to consider...

Client Service Computing

I'm starting to move away from the term "SOA" - I'm slowly starting to replace it with more specific terms. One is 'Client Service Computing', which focuses on a real simple use of clients to consume services (or composite services).



A second term that I've been using is "Service Network Computing" which focuses on the plumbing that makes hokey Web 2.0 applications capable of performing 'business critical' applications.

A View of Competing Interests and Concerns

One of the overarching themes of the Web 2.0 discussion we've had today focused on "Putting the User at the Center of the Universe". I wanted to make sure that we didn't leave off the other competing interests.



We always have to balance the needs of the business with the needs of the user. Our next generation architectures will be funded to enable next generation products, services, business models and value chains. And both User and Business will have architectural requirements which must be met. Perhaps taking a secondary seat is the needs of the developer. The hokey use of DHTML, AJAX, etc. perhaps is the most obvious indicator - we're jumping though hoops to meet the needs of users and business - IMHO, the way it should be until we get next-generation tooling.

Web 3.0 Maturity Model

I'm attending the Spark conference - a Microsoft sponsored event to discuss SOA, Software as a Service and Web 2.0.

The conversation has been a bit chaotic. It is clear that we are covering a lot of ground - perhaps too much ground. Architecting the future using terminology that is not baked isn't easy. All of the participants come from different backgrounds and have different views of what SOA is - what SaaS is - what Web 2.0 is. And no, we weren't able to find the silver bullet. I think we did make progress in finding some common ground about what is 'new' and 'different'.

The conversation has inspired a few thoughts around the aforementioned subjects. Again - no answers - perhaps more questions.

One of the discussion topics was Web 2.0 - although there was no conclusion on the tenets/philosophies of Web 2.0 a handful of attributes were repeated: User Centric, Self Service, Collaborative, Participative, Communal Organization, Lately Bound Composition, etc.

This led to yet another discussion about lack of 'mission critical' capabilities of the Web 2.0 and started the discussion of Web 3.0 - perhaps focusing more on the needs of the corporation. I put together the following illustration as a way to frame a discussion around the Web X.0:
What are the technical barriers?
What were the technical enablers?
What new capability did this enable the user or business?

Web Me Too, Oh...

I've had to take a good look in the mirror. It has not been easy. Today, I am confessing:

I am a "Web Me Too, Oh..." guy.

Yes, I failed to fill out the proper paperwork and declare myself an official Web 2.0 guy prior to the November 2005 deadline. Now I must wear that humiliating "me too" badge.

I've been told that I'm not allowed to skip directly to Web 3.0 due to some amendment that Tim O'Reilly put into law. Apparently, Web 3.0 will be released but only at a secret conference of uber geeks that write mean things about Microsoft and donate to EFF.

In the meantime - I too am attending SPARK. Let's get real... we've got a major shift going on in the presentation layer, collaboration, content management/distribution and self-service programming. The discussion has shifted from REST, WS-*, etc to client consumption models, combining multiple services, utilizing markdown languages and light weight scripting languages.

It is very clear to me that the Web 2.0 movement will drive the demand for SOA. Perhaps more importantly, Web 2.0 will mandate the technical requirements for SOA. The Web 2.0 manifesto is the requirements document for SOA 2.0.

More SOA Consolidation...

Forum Systems has acquired SOA security vendor, Kenai Systems.

Here is the updated SOA acquisition list...

Now, for a prediction - we'll see one more acquisition in February and two more in March. They'll be in three different spaces, one in each: "Run-time Monitor & Mediate", "Governance" and "Registry/Repository".

The Sheep that Shit Coleslaw

'The Sheep that Shit Grass' was a popular meme in the P2P days. If I remember correctly, it was introduced by Cory Doctorow as an economic model whereby the consumption of a material (grass) and a function (digestion) led to a byproduct that was itself consumable (more grass). This model may be contrasted with the consumption-only model, whereby the output (User Interface) is only consumable by a human, not a machine.

---

Peers
In peer-oriented systems, a node is a considered a 'peer' when it is both a consumer AND a producer. In a network, it is advantageous to have nodes not only consume value from the network, but also produce value back to the network. The more producers on a network, the more valuable the network is for consumers.

---

Non-Recombinant Systems
Traditional applications were often designed whereby the ultimate consumer was hard-coded at design time, and that consumer would be a human - and the vehicle would be some kind of graphical rendering. This is most likely a tradition held over from mainframe and client/server days. Today, many systems continue to fall victim to the same design center. Architects continue to assume that the data or functions would never be needed by anyone but a human and that whatever tool they built would be the final tool for consumption. In essence, the designers failed to anticipate future consumption scenarios that may have been out of scope of the 'Use Cases' that they built their system for.

---

Recombinant Systems
When an application is designed so that its functions or data can be discovered and used, we say that the application is 'highly recombinant'. This means that the services that are offered can:
1. Easily be found (often on the screen that used them) and
2. Easily be called (the barrier to usage is low).

Applications that are highly recombinant offer the potential for reuse, or sharing. These applications do not assume to know the future uses of the functions or data. The fundamental notion is that the true uses of the functions/data will not be known until after the system is put into production.

---

Exposing Functions and Data
As we move into a service oriented world, we have the potential of serving up two interfaces: one for human consumption (the screen) and one for machine consumption (the service).

The key is to make sure that the people who use the systems can easily gain access to the services. As an example, it is common for Blogs to identify their feeds via the classic RSS image: . Just as easily, we can tag our more structured SOAP services with the WSDL image: . Publishing and advertising consumption scenarios must become second nature for organizations that wish to leverage the advantage of recombinant applications.

---

YOU WILL EAT CARROTS!
Architect - "You will eat carrots!"
User - "But I want coleslaw..."
Architect - "You will eat cabbage!"
User - "But I want coleslaw..."

Enterprises and SaaS vendors must not only acknowledge that we are moving into an era of recombinant platforms but they must also take the necessary steps to enable the mashups, remixes, composite applications or whatever you want to call them. The future of software is about the creation and utilization of building blocks. It is about letting our users play with their Lego's. It is about allowing them to make coleslaw from their carrots and cabbage. It is about productivity and creativity. We do it for a few reasons: it lowers new software development costs, significantly reduces maintenance expenses, while simultaneously gives the users what they wanted.

You can have your carrots and coleslaw too.

SOA Pilot Program

REGISTER HERE

---

IMPLEMENTING A SUCCESSFUL SOA PILOT PROGRAM... A WEBINAR ON FEBRUARY 2nd, 2006 at 2pm EST/11am PST

As you work to extend IT capabilities utilizing SOA, a key for many organizations is a pilot program which enables the greater understanding and methodological deployment of Web services and SOA around a structured initiative. Join us as executives from MomentumSI and Actional will present best practices for selecting and implementing a successful SOA Pilot:

- Determining the Overall Goals of an SOA Initiative
- Criteria for a SOA Pilot
- Case Study of Successful Pilot Program
- Nexts Steps to an Enterprise SOA

This Presentation clearly identifies the axioms and best practices that underlie achieving SOA objectives...

WHO SHOULD ATTEND: IT Executives, Enterprise Architects, Business Line Manager and Project Managers who are using or planning to use Web services or creating an SOA! Webcast will start promptly on February 2nd at 2:00pm EST/11am PST.

---

REGISTER HERE

The Value of Reuse in SOA

The MomentumSI SOA Team recently published a brief on 'Reuse in SOA'.

See:
http://www.momentumsi.com/SOA_Reuse.html

SOA Contest - Early Results

We have some early results on The Great Microsoft WSDL's Hunt. I've looked around myself and they're not as easy to find as you might think. I'm still encouraging any and everyone (including Microsoft employees) to send me the WSDL's!!

I also published the names of a few Microsoft products that likely have WSDL's.

Come on Microsoft - we're on year 5. Surely you've got more than 4 WSDL's???

SOA Consolidation

The acquisition of Actional by Progress is yet another sign that the SOA space continues to mature. Consolidation is a necessary fact of all market places.

We've noticed that the 'acquisition trail' is becoming more and more complicated, so we've put together a cheat-sheet to help you out:

SOA Consolidation

And congratulations to the teams at Actional and Systinet!

Microsoft SOA Contest

The Great Microsoft WSDL Hunt


SHOW ME THE WSDL!!

MomentumSI is sponsoring a contest to see if anyone can locate the Microsoft WSDL's! Yes - anyone can win an SOA Tee Shirt, even Ray Ozzie!

All you have to do is:

1. Find a supported WSDL from ANY current Microsoft product (hosted or shrink-wrap)
   
2. Send me (jschneider at momentumsi.com) the name of the product and the WSDL as well as where you found it (URL, etc.)
   

Rules:

1. The product has to be from Microsoft, the most current version and supported
   
2. You can send as many WSDL's as you want (but you'll only win once)
   
3. Only the first person to send me the WSDL wins
   
4. I only have about 100 tee shirts left - when I'm out of tee shirts the contest ends.
   
5. Don't send anything confidential.
   

---

When "The Great Microsoft WSDL Hunt" is over, I'll publish the results.

SOA-WS and CORBA

IMHO - here are some of the major differences between SOA-WS and SOA-CORBA. Perhaps Steve V./Eric N./etc. would be kind enough to give their list.

Differences:

1. ALL major infrastructure vendors are supporting the Web services stack - do you remember when Microsoft threw CORBA under the bus?
   
2. ALL major application vendors are moving their ERP/CRM/etc. products to a service-based platform; how many application vendors redesigned their products for CORBA?
   
3. THE major desktop productivity suite, Microsoft Office, will be capable of locating, publishing and consuming web services; I don't remember office productivity doing much with CORBA...
   
4. SOA-WS has put significant emphasis on long-running and asynchronous programming models, enabling B2B activity. Did CORBA do much in B2B?
   
5. SOA-WS has put much more emphasis on network routing - enabling 'virtual services' and in-the-network transformations, mitigating the 'versioning problem'. These are lessons learned from the CORBA days...

I'll leave the discussion on IDL/IIOP/Common Facilities/etc. to the experts...

Legacy Architects and SOA

"Jeff - I've seen 5 paradigm changes - this one looks just like what we were doing 10 years ago with CORBA. I'm not sure why you expect anything different..."

I often find myself attending meetings with 'legacy architects'. You know the kind - the guys that love to remind you that 'nothing is new' - hence, we shouldn't expect any new results.

---

Thoughts...
1. 'Legacy Architects' or 'Last Gen Architects', if you prefer, remain quite ignorant about SOA-WS.
2. In a paradigm shift, 'Pessimistic Architects' have a much higher likelihood of failure than 'Optimistic Architects'.

I don't mind ignorant architects - however I have a true disdain for perpetually ignorant architects - the kind who refuse to learn what they don't know. These people can kill an SOA program. Find them - remove them if you can, contain them if you can't.

Pessimistic architects are good; perpetually pessimistic architects are bad. If the people leading your SOA program don't believe in SOA - you are likely doomed. Understanding the limitations of a computing model doesn't take a great architect - quite frankly, any half-assed architect can find holes in any model. Great architects are the ones that mitigate holes and while getting the entire organization completely pumped up about making the transition. Great architects push the acceptance over the chasm - past critical mass. They will have plenty of arrows in their back - mostly shot from the bows of 'perpetually ignorant architects'.

Web Service Architecture Tenets

When it comes to SOA, what do you believe in?
What are the goals? What are the rules?

These are tough questions that many people in the industry have attempted to answer. Some time back, Frank Martinez and I wrote our view:

Web Service Architecture Tenets

I'd love to hear your feedback.

My Favorite Prediction

I've read quite a few predictions for 2006 - and my favorite - by far - was penned by David Heinemeier Hansson. His prediction on enterprise software follows:

4. 'Enterprise' follows 'legacy' to the standard dictionary of insults favored by software creators and users. Enterprise software vendors' costs will continue to rise while the quality of their software continues to drop. There will be a revolt by the people who use the software (they want simple, slim, easy-to-use tools) against the people who buy the software (they want a fat feature list that's dressed to impress). This will cause Enterprise vendors to begin hemorrhaging customers to simpler, lower-cost solutions that do 80% of what their customers really need (the remaining 20% won't justify the 10x -100x cost of the higher priced enterprise software solutions). By the end of 2006 it will be written that Enterprise means bulky, expensive, dated, and golf.

What David identifies is the growing distinction between classes of applications in the enterprise. Many, if not most, applications in the enterprise DON'T NEED TO BE ENTERPRISE GRADE. The function that they perform - isn't that important, doesn't require .99999 up-time, DOD-grade security, etc.

But let's get serious - Dell isn't going to be running its order management system from some Web 2.0 SaaS startup - nor will e-Trade be hosting customer financial data in some "non-enterprise" way. People who don't do enterprise development don't understand enterprise development; there are a million blogs out there to prove this. An enterprise can lose more money in one day because of a system outage than the combined revenue of every SaaS / Web 2.0 company combined.

Before 'enterprise Java', the term 'enterprise' referred to the scope of the deployment - not the architecture. 'Mission Critical' was the term we used to indicate a high degree of architectural integrity. David (and many others) are continuing to restate the obvious: we need multiple levels of architecture: light, medium, heavy. We need architectural profiles for each level. Our enterprise architecture teams MUST NOT force one design center for all application classes.

Is there a place for RoR, Spring, RSS, etc. in the enterprise? You bet. Will light weight solutions eat away at their heavy-weight counterparts? Yep. Is the 'enterprise' grade solution going to mean "bulky, expensive and dated" in 2006? Well, yea - it has meant that for years!

My 2006 Predictions

Here are my 2006 predictions:

1. Virtually no enterprise software companies will 'go public' in 2006.

2. U.S. based venture capital will continue a downward trend with enterprise software leading the pack.

3. An abnormally high number of small ISV's will fail to raise their next round of funding. However, their revenue will allow them to crawl forward forcing them to ask the 'startup euthanasia' question.

4. On average, large enterprise software companies market valuation will stagnate; small and medium sized companies will mostly go down except for brief periods of 'acquisition hype'.

5. The number of 'Software as a Service' providers increase substantially but find low revenue in 2006.

6. The competition between Big-5 and Big-I (Indian) consulting increases significantly setting up a 2007 consolidation scenario.

7. The Business Process Platform becomes the accepted standard as the foundation for enterprise software.

8. SOA continues as a major trend however more attention is focused on 'what to service orient' rather than 'how to service orient'.

9. Google continues to release new products in very short time frames. Microsoft takes notice but does not act.

10. Salesforce.com stock price drops by 50%.

Busting the UBR Revisionists

I'm sorry - that whole thing about the UBR being an interoperability test really bugged me. And it wasn't just Microsoft that sent out the BIG FAT LIE, IBM did it too.

So, how do you prove 'revisionist' thinking on the web? That's easy - you go back in time. Yes, you visit the WayBackMachine!

And I quote from the Microsoft UDDI site:

"How can you get involved in UDDI? If you are a business, you need to start thinking about how you will transition your company to the world of Web Services. IT architects should read through the UDDI specifications and start thinking about which Web Services your company will define and publish in the UDDI Business Registry. If you are a software developer, you should download the Microsoft UDDI SDK. If you are a software company or an ecommerce portal, you need to start thinking about how you will integrate your products and services with the UDDI Business Registry."

Or do you prefer this one:

Most importantly, UDDI involves the shared implementation of a Web Service based on the UDDI specifications. This Web Service -- the UDDI Business Registry -- is an Internet directory of businesses and the applications they have exposed as Web Services for trading partners and customers to use. Business programs will use the UDDI Business Registry to determine the specifications for programs at other companies in a manner similar to how people use Web search engines today to find websites. This automated application-to-application discovery and integration over the Internet will help eliminate many of the configuration and compatibility problems that are preventing businesses from more widely adopting B2B, despite B2B's potential for cost savings and improved efficiency.

What I don't understand - is how these marketing-whiz-kids thought that they wouldn't get called out on this. This is the age of the Internet - where everything is archived.

See it for yourself:
http://web.archive.org/web/20040718020748/uddi.microsoft.com/about/default.aspx

Some Past Predictions...

Ok - I nailed almost all predictions... except I missed it all by one year.

http://schneider.blogspot.com/2003_12_28_schneider_archive.html#107314457798165610

Take a look at #1, 7 & 10 - oh yea - can you say SCA?


BTW - here is the 2003 list:
http://schneider.blogspot.com/2003_12_28_schneider_archive.html#107262788720914053

And yes, hind sight is 20/20...

Obsolescing J2EE

Without a doubt, the biggest story of 2005 has been the radical obsolescing of J2EE. As much as I would like to say that the J2EE was completely obsoleted, that would be incorrect. Service Component Architecture (SCA) only makes about 75% of J2EE obsolete. Remember, SCA targets: invocation, data structure and composition mechanism.

My Java friends hate when I refer to J2EE as a "deprecated API". Of course, this is an exaggeration - no one actually deprecated the standard. More accurately, one could say that "SCA has superseded J2EE". Or if you want to be politically correct you could say, "SCA represents an abstraction layer to the J2EE component, data and invocation model." Yes, in the short term you will likely use J2EE API's significantly inside of your SCA components. But later, the vehicle of choice will likely become the DSL that 1. Does the job the best 2. Reduces the impedance mismatch.

For those of you that are building out your SOA Reference Models and Architectures, MomentumSI is now recommending a section that discusses the "SOA Programming Model". And of course the most common will be:
1. Java Web Services (JAX-RPC, JAX-M, JAX-B, etc.)
2. Service Component Architecture (SCDL, WSDL, etc.)
2.A SCA with Java only bindings
2.B SCA with XYZ bindings
3. Microsoft Windows Communication Foundation
4. A combination of 1-3 (the most common answer)

So, if we obsolete Java 2 Enterprise Edition - any guess what is obsoleted after that? Bulls eye. Ya gotta love the variation of "embrace and extend" called "Abstract, Replace and Transition"... I can just hear it now... "We warned you about the JCP!" Bam!


---- S I D E N O T E
SCA doesn't mandate domain specific languages like JSP. So, yes JSP is safe - from SCA that is. However, it is clear to me that the AJAX, Ruby on Rails and the Web 2.0 movement will redefine the enterprise reference architectures for the Presentation and Collaboration Layer. The bottom line is that the tolerance continuum allows us to use light weight protocols, dynamic languages and late binding at the presentation layer. Why? Because humans are the best 'fault handler'. Remember: "tolerance over rigidity on the presentation layer!" So although SCA isn't directly attacking J2EE presentation layer, I believe that J2EE presentation vehicles will lose to more tolerant solutions.

Is REST Needed?

Mark "I won't rest until you REST" Baker is at it again. In a recent presentation, Mark tells the population:



He goes on to state:



and the follows it up with several slides like this:


Yes Mark, you can order a pizza with SOAP, with REST, with CORBA, with RMI, with EJB and more. What's your point? The world needs REST? Let's be clear: "REST" is unnecessary - as is all of this stuff! If we want to build our distributed systems with Sockets and EDI we could - BUT WE DON'T!

Mark - if you want to compare and contrast REST and Web services than do it right. This is crap and you know it. The funny thing is, I'm a REST fan - I just can't stomach this one-sided bullshit.

Bye Bye MS UBR!

Just received this email:

You are receiving this mail because you have registered as a publisher on the Microsoft node of the UDDI Business Registry (UBR).

The primary goal of the UBR was to prove the interoperability and robustness of the UDDI specifications through a public implementation. This goal was met and far exceeded, and now the UBR is discontinuing its operations. As part of this process the Microsoft UBR node at uddi.microsoft.com will be permanently unavailable for all operations beginning January 12, 2006. Data stored in the UBR may be retrieved until January 12, 2006 and used in accordance with the UDDI Business Registry terms of use available at http://uddi.microsoft.com/policies/termsofuse.aspx. You may find the UDDI Data Export Wizard useful for retrieving your data, and it is available here: http://www.microsoft.com/downloads/details.aspx?familyid=9D467A69-57FF-4AE7-96EE.

For more information, please see the frequently asked questions related to the UBR discontinuation at http://uddi.microsoft.com/about/FAQshutdown.htm. You may submit feedback to Microsoft at the following location: http://uddi.microsoft.com/contact/default.aspx.

Thank You,
Microsoft UDDI Team

Did I just read that..."The primary goal of the UBR was to prove the interoperability and robustness of the UDDI specifications through a public implementation." Revisionist history is a true thing of beauty. Any chance Microsoft could resend it the email and replace the aforementioned sentence with this one:

"The UBR was a really dumb idea and we apologize for making you sit through lectures on a service oriented yellow pages hosted in the cloud."

Mr. Don Box,

Mr. Don Box,
It wasn't too long ago that you were sniffing around JBI - asking all the right questions. It was clear that you had concerns - as did I.

That said, what's your take on 'Service Component Architecture'?

More precisely, do you agree with the approach given the capabilities of the Java language (and knowing that the Java binding was key)?

Secondly, do you see an SCA binding to .Net components being valuable for your large customers that have mixed platforms?

Respectfully submitted,
Jeff

SCA and Location Coupling

For some reason, I'm fairly obsessed with coupling. I've written a few things on the subject: Dynamic Coupling and A Coupling Index.

I've been monitoring the progress of the IBM/BEA Service Component Architecture for quite some time now. One area of interest to me is the concept of 'spatial' or 'location' coupling (or decoupling, if you prefer).

On many occasions, developers create a model whereby they make an assumption about the caller:

1. The caller will be local (not incurring network issues)


2. The caller will be remote (incurring network issues)

In our quest to progress down the decoupling continuum, the issue of 'location assumption' must be addressed. Hence I was quite pleased to see the following text in the SCA whitepaper:

"Components and their service interfaces can be designed for purely local use by other components, or components can be designed for remote access, either from other parts of the business or from other businesses. Local components can use interfaces optimized to exploit the co-location of the service client and the service implementation. Services designed for remote use must take account of the potential for the client being connected over a remote link and so must offer interfaces that are compatible with this remoteness."

I've been wondering... what will end up being a bigger event, the release of SOAP/WSDL or the release of SCA/SDO. Only time will tell.

Refabricating Architecture

I just finished reading the book, Refabricating Architecture. The book isn't about software; the domain is the architecture associated with 'building construction' (apartments, homes, etc.) I enjoy reading these books as part of a personal cross-training program. There are a couple items that I wanted to share:

"The way to art in much twentieth century theory and practice would be by means of a thorough transformation of production. Architecture as a mass-produced product would transform both access and perception; it would become a thing, a commodity, a vernacular shelter for the twentieth century. Great architecture is today equated with art. Commodity, most believe is the creed of the philistine. It is possible, however, to see commodity instead as the crucible of art itself and to recognize the process engineer - not the design engineer - as the high priestess of this new art. It is not the engineer as the designer of artifacts that we applaud, but rather as a designer of processes that show the way forward in art."

Authors, Kieran and Timberlake, go on to state:

"The single most devastating consequence of modernism has been the embrace of a process that segregates designers from makers: The architect has been separated from the contractor, and the materials scientist has been isolated from the product engineer"

First, let me state my position. I am interested in the commoditization of software architecture. I am embarrassed by the current state of voodoo architecture, wizard architects and clean-sheet implementations. Don't get me wrong, I'm not stating that we should quit inventing or innovating. There is a place for 'material scientists', just not inside of every Fortune 500 I.T. shop...

SOA has the potential to act as the 'material enabler' of the commoditization of software architecture. Modern methodologies will act as the 'process enabler'. Pure and simple - this is my goal. I realize that wizard architects will refute this. They'll hate the concepts of the software factory, mass customization, template architecture and meet-in-the-middle methodologies (not top down). It attacks their creativity and their personal income potential. The true professionals however, will see the ultimate value and find the art in the discipline.

I Hid the Turd

Dear Mr. CIO,
I regret to inform you that I've been hiding a massive turd from you and the business units for several years now. The turd is the "3-tiered silo application". The stench was horrid - I was forced to get some industrial grade air fresheners that I called "EAI and ETL". I feel very bad about this, as does my staff. Although, there were several times where you called us into meetings and we all had those 'shit-ass grins' on our face and you thought we were making fun of you - good news - we weren't, we were laughing about our hidden turd.

But I don't take all the blame. You remember when you asked us to do 12 major initiatives and we told you that we didn't have the staff? Yea - well, we didn't. So we cranked out as much as we could and patched the crap together with messaging. From an architectural perspective, it's a freaking mess!! We've got data replication, batch transfers, multiple message formats, multiple transports, platforms, vendors - wow, I can't believe you didn't fire us!!

The reason that we are 'coming clean' is because we believe we've found an answer. It turns out that using simple protocols and a network programming model that isn't vendor specific will allow us to build connected systems. Also - we discovered this other wacky thing - this new model called SOA actually aligns to the needs of the business.

Now that we're being honest with each other, I feel it necessary to inform you that this SOA thing... is right, but - it actually takes a bunch of planning and architecture. It's like - ya-gotta-use-your-brain-kinda-stuff. And not to drop another bomb on you - but a bunch of these guys around here are morons. Now, I know that you have deep pockets and short arms and don't like to pay for real talent, but I think your screwed if you don't. So, it's your call.

In the meantime, the Turd guys, came up with this new turd-containment concept that they call an ESB. I don't know what it stands for but I talked to some smart guys and they said that it was supposed to be SOA but the vendors missed their deadlines - so they just repackaged their old turds with some new SOA stuff. So, just beware - were probably going forward with the turd-containment stuff and later we'll have to go with real SOA stuff. Sorry for hitting you with all of this.

Sincerely,
Your Entire Staff

Requirements & Specifications in Service Oriented Systems

I couldn't help but notice that the cover story for CIO magazine was about the requirements process and the awful state that it is in. I tend to agree. When I visit customers I see one of two things:
1. The company has perfected requirements for silo based systems
2. The company stinks at requirements all together

I've looked at many systems that people wanted to upgrade, rewrite or replace using service oriented techniques. As a habit, I ask for the original requirements document for the production system. I then play this game to see if I can trace 'silo' or 'closed' characteristics back to the orignial requirements and specifications. In general, these characteristics are usually described in the 'supplementary specification' or in a supplemental 'non-functional requirements' document. And in virtually every case I am able to trace the issues back to the original documents.

One of the significant changes in the 'service oriented enterprise' is an renewed emphasis on: portfolios, product lines, business processes, enterprise requirements and cross-cutting concerns. We are stressing to our customers that they MUST revisit the requirements process and move to an 'enterprise grade' method. That said, I am proud to announce a new course from MomentumSI, "Requirements & Specifications in Service Oriented Systems"

The course is directed at the Business Analyst, but would valuable for anyone that participates in the requirements & specification activities.

---

Course Outline

• Overview of SOA for the Business Analyst
  
• The Business Impact of SOA
  
• The Awesome™ Method for Business Analysis
  
• Strategy, Portfolio Analysis and Business Case Development
  
• Generating Stakeholder Requirements
  
• Coordinating Enterprise Requirements
  
• Validating Stakeholder Requirements
  
• Generating Engineering & Procurement Specifications
  
• Managing Change throughout the SDLC
  
• Examples and Cases

---

I firmly believe that those companies that continue to use 'silo based' requirements processes will fail in adopting SOA. We will begin offering this course in January. If you're interested in the full course description, just send Alex an email: arosen [at] momentumsi.com

The SOA Ecosystem

MomentumSI is a consulting company that specializes in SOA. We help companies with their SOA strategy, plans, vendor selections, architecture, infrastructure, education and business projects. In this role we have a birds-eye view of the SOA landscape, and one thing is clear:

"An SOA Ecosystem is quickly evolving and those inhabitants that fail to recognize the rules of the system will likely wither and die. "

In the year 2005, one significant event took place in the SOA ecosystem. Vendors that were amorphous found shape and structure. Full fledged product categories emerged: SOA Registry & Repository, SOA Management, SOA Intermediaries, SOA Governance, SOA Security, SOA Data Services, SOA Process & Workflow, SOA Testing and SOA Legacy Integration.

As the organisms explored the ecosystem, they found each other. They stared, sniffed and prodded. They identified competition, but most importantly many of them found cooperation. After first contact, emphasis was placed on removing their overlap and short-comings and they began the process of morphing themselves to become "SOA Eco-Friendly".

The SOA Ecosystem will be governed by the laws of all ecosystems. And I strongly encourage those inhabitants to know the laws:

• Symbiosis is an interaction between two organisms living together in more or less intimate association or even the merging of two dissimilar organisms.
• Parasitism, in which the association is disadvantageous or destructive to one of the organisms and beneficial to the other.
• Mutualism, in which the association is advantageous to both
• Commensalism, in which one member of the association benefits while the other is not affected.
• Amensalism, in which the association is disadvantageous to one member while the other is not affected.
• Predation is an interaction between organisms in which one organism, the predator, attacks and feeds upon another, the prey. (wikopedia)

I've been flying around the country talking with large and small SOA product companies about the ecosystem. As a preferred 'SOA integrator' we see the problem from the view of the customer. And as the champion of the customer, we are unable recommend products that exhibit characteristics which negatively affect the customer. Examples include:

1. Portfolio Coupling - Single vendor solutions mandating a daisy chain of products all from the same vendor. Example: If the vendors Process Server requires the vendors ESB which requires the vendors Application Server and the vendors Database Server.
2. Product Coupling - A single product that contains multiple capabilities, where each capability is really a standalone product. (First generation BPM products fell victim to this).
3. Closed System - A product that fails to have integration points into the other inhabitants of the SOA ecosystem. We don't have the equivalent of a J2EE specification for the service oriented / Web service world. The burden to identify and specify integration points and mechanisms is placed on the vendors by the customers and consultancies.
4. Inch Deep, Mile Wide - In the early days of SOA, many vendors were chasing the 'SOA platform'; they provided a little bit of registry, a little bit of orchestration, a little bit of mediation, etc. but failed to excel in any one area. The Darwinian nature of the SOA ecosystem will kill off those vendors that fail to specialize (a mile deep). IMPORTANT: This will force some vendors to abandon entire products or modules and to replace this functionality with 'open system' integration points to best-of-breed providers.

The SOA ecosystem must place the customer at the center. Modern SOA infrastructure must be capability oriented and loosely coupled via standardized policies, metadata, protocols, formats and identifiers. Vendors must recognize the architectural ecosystem, the elements, their relations and constraints. As corporations spend millions of dollars to decouple applications, they MUST place an equivalent emphasis on procuring from those vendors have eco-friendly offerings.

Judith Hurwitz on SOA

With the boot camp consuming my time, I've had to queue up lots of blog posts on recent topics (SOA Maturity Models, Frankenstein, SOA Analysts, Big 5 SOA methodology / scribblings, etc.) But I thought I'd lead with a piece found at the CIO magazine - only because the Judith/CIO magazine combination influences a crowd that needs correct information.

Judith Hurwitz presents her 'ten principles of SOA' in a piece on SOA: Battle of the Titans. My comments follow.


SOA is real. It is not a quick fix. It is a ten year journey (or longer) that requires considerable planning. It is also as profound and far reaching as, for example, e-commerce.

Agreed.

SOA is build upon 15 years of experiments in creating highly distributed computing environments that take into account everything from load balancing, software distribution, security, and data management including meta data management and registry. SOA embraces all these aspects of computing and takes them into account.

Agreed.

SOA will only work if organizations lead with manageability. SOA by its very nature demands the aggregation of IP from many different sources. Scalability within SOA will come from managementÂ?not development.

It was funny listening to all of the vendors at the boot camp. Each one told us what to lead with - 'Lead with the Registry!', 'Lead with Mediation!', 'Lead with security!'. Now Judith might be talking about SOA Manageability or about general governance - it's impossible for me to comment on what she meant. Regardless, I'm comfortable stating that you should lead with SOA strategy and incorporate a closed loop infrastructure. All of the components must complement each other - no one component is at the heart.

SOA will only work if it is implemented within a business process context.
SOA is predicated on leveraging business services that constitute the component parts of your business.

Yea - this is wrong. It is common for a newbie to watch a demo of BPEL/XLang/BPML orchestration and think that they just saw the future of computing. Better yet, they grasp the concept of a 'business service' but fail to realize that this is the ONE thing in SOA that will see the LEAST amount of reuse. Don't get me wrong - there will be some instances whereby SOA enables process-driven applications, but this is merely one of a dozen or so benefits.

SOA requires a container that creates a composite application.

I'll remind Judith that she characterized SOA as working in "highly distributed computing environments". Service based applications come to life by activating services in well known sequence. The composition (or invocation) of these services are distributed. The app server/container metaphor takes on a new meaning. Service oriented applications have 'invocation points' or 'composition points' at multiple layers in the architecture (virtual business service, business service, virtual data service, data service, etc.) The key here is to not accidentally use the term 'container' in the singular. How about, "Composition of service based applications is usually distributed, with no central composition point or single container."

SOA requires standards that can be depended upon across all vendors implementations of SOA.

The ONE truth about SOA is that we CAN NOT DEPEND on standards across all vendors implementations. If you don't understand this, you don't understand SOA. The reason that SOA will work is because we have factored out the non-functional concerns and created transformable protocols, formats and identifiers of the standards which are MEDIATED.

SOA assumes that you will begin to write applications differently as a series of tightly defined services implemented in a loosely coupled manner.

I guess... :-)

SOA assumes that each component part is equipped with a clearly implemented web services interface based on standards.

Agreed. They just don't have to be the 'Web Service' standards, nor do they need to be ubiquitous. They just need to be federated, virtualized and mediated.

SOA dictates that change is the norm since this approach to software mimics the way a business operates and evolves.

SOA is a pain in the ass that, in the short term, will slow down your ability to rapidly deliver software to your customers. SOA doesn't provide rapid change but it does provide a framework for 'scaling capability'. As the number of enterprise concerns rise (consistent data, consistent logic, fulfilling regulatory mandates, process as a first order concern, one-face-to-the-customer, etc.) we need a framework to allow us to change EXTREMELY complex systems. SOA enables the insertion of capabilities in an incremental (and almost linear) manner.

SOA is complex. Explaining it to CIO's is even harder. I wouldn't expect Judith to go to the detail that I just did for the audience she was catering to. However, the amount of poor advice provided is, in my humble opinion, disappointing.

SOA Boot Camp: Days 14, 15, 16 & 17

It's done. Thank God - boot camp is done.

17 days of training seemed like a lot and it was. My friends were joking that I wasn't trying to train the consultants - I was trying to brain wash them. Well - perhaps I was. But it was great for them to hear different views of the same story from so many different people. By the end of the boot camp we had almost 20 different instructors participate. I really need to thank Hjalmer, Melissa, Stephen and Alex for supporting the effort. They did everything from booking hotel, air, car to making sure we got fed - to validating content. I couldn't be happier with the team effort.

Well - the boot camp ended just as strong as it had begun. We were lucky enough to have Sam Boonin from Cisco present the AON vision. I must admit that Cisco has the unique ability to make a complex topic seem simple. Their proposition for relocating functionality from the application layer to the network layer is profound. Naturally, we pushed them a bit on the standards support which was less than what we'd hoped, but it was clear that it was in Cisco's best interest to move the standards forward and that they were on the right path.

And if the Cisco vision wasn't big enough - we followed it up with Microsoft. Our discussion started with a history lesson (COM, DCOM, remoting, WSE, Indigo, WCF) and quickly led into the next generation tools. We went over the new white boarding capabilities in Visual Studio (formerly White Horse) and then was briefed on BizTalk orchestration (and next-gen human workflow). It is clear the Microsoft will be an on-going leader in the SOA space.

We were also lucky to have Peter Yared and his crew from Active Grid talk to us about their next generation tools. His team has done an amazing job of enabling software developers to be productive in no time at all. Peter also made it clear that the 'service oriented' design center was core to his product road map.

The last vendor session was on the SAP ESA story. Our own Scott Campbell presented the SAP vision for service enabling EVERYTHING. SAP is breaking away from their past of being only a packaged application solutions provider. With NetWeaver they are pushing infrastructure (Java, Portals, etc.) and are doing it all with an SOA facade.

And naturally we went back and covered the basics - even managed to get a bit of BPEL coding in. Boot camps are a ton of effort - but at the end, you feel good about what you've accomplished - and you've made a bunch of friends. We passed out boot camp tee-shirts - and headed home to see if our wives still loved us. I declared it a success. We've opened up additional SOA consulting positions and have scheduled the next boot camp for the 2nd week of January.

SOA Soldiers Wanted - the weak need not apply.

SOA Boot Camp: Day 13

After two days of rest we returned to boot camp in Austin where Luc Clement and Chuck D'Antonio of Systinet arrived to update us on the status of Systinet's Blizzard Platform. Many boot camp participants have pointed to Systinet as playing a crucial role in SOA governance. Their Governance Interoperability Framework (GIF) has gained traction among several of our key partners so we were eager to hear more details from the source. Clearly the company has an aggressive set of capabilities they are looking to build out and we were able to drill down on their current and upcoming products.



Luc started out by building the case for SOA governance. We have been discussing this daily but Luc has been probing multiple customers and developing an excellent list of challenges being faced in the field and Systinet's roadmap to solving them. The focus this year is around policy management but provisioning challenges are going to be addressed soon.

There have been many controversies around the UDDI spec and it was excellent to hear Luc's point of view about how the spec developed (including Bill Gates' role) and what parts should be ignored. Systinet dominates the UDDI compliant registry space, but where the registry maintains references only, there is a need to manage the metadata that is an essential component of a contemporary SOA. Luc helped clarify what the Systinet repository product will and will not do and how they avoid creating overlap with other repositories.



Luc also gave us a look at Contract Manager. This product pushes SOA metadata to a necessary further step that involves tracking service consumers rather than just the producers. Solving many the lifecycle management challenges SOA presents is going to require this additional knowledge in the infrastructure.

Chuck led a drill down into the Registry product including the process Systinet is using with their customers to bring a registry up. While some people cringe when the subject of UDDI tModels comes up, obviously Systinet knows this stuff cold and Chuck helped the team get a solid grounding and understanding of some of the finer points. When deploying Registry, Systinet leads their clients through a workshop process and Chuck helped us see inside how Systinet is approaching the design decisions involved in creating initial taxonomies and how we could add value to the process.

As night fell Chuck took the team through a deep dive into Policy Manager. Policy permeates an SOA and we have had heated discussions about where it should be created, stored, and managed. We were pleased to hear the degree to which those designing the product are engaged with its earliest adopters. We'll be working with the product in our lab to help guide their efforts as well.

SOA Boot Camp: Days 10, 11 & 12

Day 10 was the culmination of a lot of hard work; we took all that we had learned about clients, services, intermediaries, architecture, design and pulled it all together under the 'composite application' umbrella. Deborah Scharfetter, VP of Products from Above All Software walked us through the advanced features of their application composition suite.

Above All definitely understands the idea of rapid composition. Their suite in some ways looks like a 'service oriented powerbuilder'. They have some interesting design concepts in the product: 1. Leverage SOA whenever possible, but don't punish the user if SOA isn't possible 2. Make it easy to tap into packaged applications (SAP, Siebel, etc.) 3. Leverage WYSIWYG concepts to enable rapid development 4. Assume that there will be multiple delivery channels (thin client, portlet, rich client, mobile client, etc.) 5. Services will be combined with other services to create composite services, which in turn will be exposed to the service network.

For some reasons "SOA" doesn't seem to hit home until people see a user interface on it. Composite applications seems to create that 'aha' momentum for many.

Day 11 focused mostly on managing & monitoring services in an operational environment. Jason Hollander and Chris Bowlds from Actional went over their SOAPstation and Looking Glass products. Both products looked strong. It was also clear that Actional was taking a stronger interest in the security side of equation than many of the other vendors. SOAPstation has been carefully designed to do both fine grained and coarse grained access control. This is in addition to a real nice UI for quickly adding in ws-sec attributes (signature, encryption,etc.)

The Looking Glass product focuses on the monitoring of services. The product appears to be well designed and full-featured. However it is unclear to me how it will compete/complement with the Tivoli/BMC/HP trio. I really like what Actional has done I just see a potential crash course with the big three. For now, they'll have no trouble fending them off - their offering is advanced and buyers that need a solution today will find an easy answer.

Day 12 we split into teams and continued building out some of our reference architectures. We are close to finishing our SOA Security Reference Architecture - we just need to add a bit more around fine grained access and vulnerability detection. We also made progress in knocking out an XML Firewall Buyers Guide (we'll publish it soon). Lastly, we did a first draft on our 'SOA Operations Management Reference Architecture' and 'SOA Presentation and Channels Reference Architecture' (plenty more to do here!)

By the end of the day on Saturday - we all were starting to feel like this was really a 'boot camp'. We're tired - we all hopped on planes and headed home to see our families. We'll kick it back in gear on Tuesday...

SOA Boot Camp: Days 8 & 9

Day 8 (Tuesday) was an interesting day. Oddly enough we were discussing service networking infrastructure (XML transformation devices, mediation and XML firewalls) - and the press release around IBM picking up DataPower came out. Well - that created a bit of discussion. Generally we agreed on a few things: 1. The deal was good for IBM and DataPower 2. The valuation of Reactivity just went up 3. Cisco needs help with AON. We also spent some time and knocked out a 'service networking buyers guide' which we will make available to our customers.



Day 9 (Wednesday) focused on 'service oriented business intelligence'. Eric Zerneke and y of Service Integrity taught us the essentials of using SIFT. This was a welcome change. We'd been spending a significant amount of time looking at the non-functional concerns of SOA that it was great to learn about a product that was much more focused on providing business value. From a geek perspective, SIFT focuses more on the information found in the SOAP body. So, many people talk about 'business services' - well, accompanying those services are 'business messages'. SIFT presents a solution for 'intercepting' business messages, applying cross-message analytics for the purpose of near-real time event resolution. Unlike traditional ETL/Cube/Analyze/Report solutions, SIFT presents information to a user when the information is still action-able (not post-mortem analysis). They also do a great job of aggregating the data and making it available to a variety of output devices (rich client, portal, etc.) One thing that I'd like to see is a closer integration into intermediaries.

SOA Boot Camp: Days 6 & 7

Day 6 (Saturday) focused on SOA security. We started off by reviewing the typical security concerns found in a distributed computing world: message authenticity, confidentiality, non-repudiation, distributed trust, etc. Part II reviewed the protocols available to remedy the issues: (WS-Security, XML-Signature, XML Encryption, WS-Trust, WS-Federation, SAML, TLS, etc.) Part III reviewed the actual architectural elements that implement the remedies (XML Firewalls, I&AM, Federated Identity, PKI, platform libraries (AES, etc.), intermediary based PEP's, etc. Part IV focused on the Momentum SOA reference architecture (usage of protocols, reference elements, architectural patterns & practices and use cases). At first glance, SOA security appears to be a real beast, but once you break it down it is actually not too bad.


Day 7 (Monday) was an in-depth review of 'decoupling in the network'. Frank Martinez of Blue Titan discussed the protocol resolution to the non-functional requirements of distributed computing (message formats, passed predicates, transports, reliability, security, transactional integrity, etc.) And how each of those issues can be viewed as potential coupling issues. He then addressed the use of intermediaries to mediate the differences between architectural participants. The outcome was an architectural approach that promotes consume-ability by making a service tolerant to the various requirements imposed by clients.

SOA Boot Camp: Days 4 & 5

I was way too tired to blog about the boot camp last night - so now I'm playing catch up...

Day 4 focused on service design: best practices in message creation, encoding types, scoping the port types, importing common types, etc. We all agreed that the current documentation around 'best practices in service design' is still pretty weak.

We also had the whole class do contract first design - and then bind it back to platform implementations, in our case Java. As a reference, we went through Axis, ActiveSOAP and XMLBeans just to give everyone a feel for the various components.

Day 5 moved into testing. Roland Lynn and Wayne Ariola from Parasoft gave us a serious lesson on SOA based testing. Their suite has extensive capabilities for generating test suites and executing the tests across just about any configuration (encodings, transports, attachments). We were also educated on static analysis techniques and scanning for malicious attacks. The session ended with an impressive view of their SOA based load testing capability.

SOA testing is going to have to enter mainstream. It was really kind of odd to see that the state of the art in testing is beyond just about all other aspects of SOA infrastructure. Who'd of thought?

SOA Boot Camp: Day 3

Another tough SOA Boot Camp Day!


Most large enterprises have a number of legacy systems in place - and many of them running on the mainframe. SOA and Web services provide a great way to access those business and data services.

Momentum has a number of clients that are choosing to use services as a stepping stone to migrating functionality off of the mainframe. In this way they are able to create a standard interface and have the clients plug into it. Later the implementation of the interface can be moved to whatever hardware software platform they choose.


We were fortunate to have Rob Morris and Wilson Rains of GT Software educate on 'service enabling' legacy software. First, it was great to see an organization that understands both the classic mainframe environment and the next generation service oriented enterprise. Most companies that we talk with that come from a mainframe environment really don't get SOA - this was a welcome change.

The other item that we quickly noted was the depth of their product suite. We've evaluated a number of similar packages and many of them have quasi-connectivity solutions. As an ex-IBM 390, MVS, VM guy, I know that there is a real big difference between those that understand this environment and those that don't.

SOA Boot Camp: Day 2

Day 2 - Today we covered more of the advanced WS-Specs and what it means to distribute a loosely coupled systems across a network. The focus was on 'creating a virtual application' by using "RST" (reliability, security and transactional integrity).

Most of knew this stuff already so we started the 'Requirements Analysis' workflow early. The first step focused on what has changed in capturing business stakeholder requirements (processes, collaborations, interactions, etc.) The second half focused on the changes in specifying a software system (candidate services, enterprise concerns, etc.) One thing that we all agreed on is that the requirements stage has significantly changed and that we need a specialized course. We landed on "SOA for Business Analysts" which will update the RUP concepts (Vision Document, Use Cases, etc.) with more up-to-date techniques.

SOA Boot Camp: Day 1

Today was the first day of our SOA Boot Camp. For those of you that haven't heard, MomentumSI has pulled our first batch of SOA consultants out of the field for 17 days of in-depth training.

We started out covering the basics - WSDL, SOAP, and a bunch of the WS-protocols. For us, it wasn't so much of an education on the basics, but rather a discussion of how to explain these concepts to newbies. As SOA consultants one of the biggest issues we face is getting the teams at our clients on the same page by using a common vocabulary.

Although we tried to focus on the basics - we found ourselves conversing on the more interesting aspects (business value, architectural patterns, governance, etc.) It was also interesting to hear the chitter-chatter between the consultants. It sounds like many clients are running into the same basic problems. It was better to hear that the consultants are agreeing on common solutions!

Dear CIO, I Can See Your Underwear!

Not so long ago I predicted that CIO's would lose their job due to failed SOA implementations. A few people told me I was over reacting so I took some time to think it over. I'm done thinking it over. Here is where I landed:

CIO'S WILL LOSE THEIR JOB BASED ON FAILED SOA IMPLEMENTATIONS.

Here is why:
1. Unlike many past I.T. initiatives, the SOA initiatives can EASILY be audited. Frank Martinez taught me the phrase, "Show me the WSDL!" I use it all the time. I say, "How's you SOA program going? ... Really, that's great - show me the WSDL'S!" And some poor architect squirms around giving excuses and tells me that he can't do it easily... at that point, I go for the jugular and drill him on why the service definitions aren't in his registry.

2. Most organizations have completed their 'enterprise application portfolio' - often with the total number of applications exceeding 1,000. This portfolio is often referred to as the 'functional footprint'. Corporations are attempting to service enable their entire footprint. Most companies are less than 1/10 of 1% of the way there. In addition, many of them will proudly brag that they've been working on service enablement for 2 years plus. Rarely do these geniuses do the math to determine that unless they pick up the pace they won't complete their task until the 22nd century.

I talk to so many companies about their SOA program - and they all say the same damn thing: "Well, we only have X services done but that's ok because we're doing it incrementally."

There is a HUGE difference between SLOW and INCREMENTAL. It won't take long before the I.T. auditors catch on to the math. In a service oriented world, your underwear shows - there is no hiding. Organizations must determine how to create service oriented enterprises FAST, CORRECT and INCREMENTAL.