The Enterprise SOA Manifesto

Recently, the SOA camp has entered into a period of self-reflection and evaluation. Through this endeavor, the camps are dividing. There are those who feel that SOA aligns more closely with the concepts of enterprise architecture and there are those who feel that success can only be driven by more agile, quick hit wins. The optimal answer is likely somewhere in the middle... an approach that blends the best of EA with the best of Agile.

In the vein of the "Agile Manifesto", I'll post my position and invite my colleagues to offer their ideas.

First, it is worth defining Enterprise SOA. The definition that has evolved from working with our customers is,

Enterprise SOA is:

• An Enterprise IT Strategy that encompasses a set of business, process, organizational, governance and technical methods.


• It enables business agility through the use of loosely coupled services that are used as building blocks to develop composite applications that can be reused and recombined to address changing business priorities.
  

Complementing this definition is a set of supporting philosophies. Note that these philosophies are about Enterprise SOA, not just 'service oriented architecture', which has already been covered.

The Enterprise SOA Manifesto

1. Communities over Silos
   Enterprise Architecture focuses on creating portfolios of integrated software to fulfill a business mission. Although application silo's can often be created more quickly, the long term process of integrating silo's of logic, data and policy create spaghetti architecture, demoralize teams, stagnate innovation and increase long term maintenance costs. Communities (or application portfolio domains) should adhere to enterprise standards while each zone tailors the localized rules and regulations.



2. Balanced Planning over The Extremes
   Enterprise SOA attempts to balance 'planning' versus the extremes (too little/too much). The popularity of the Agile movement was largely a knee-jerk reaction to the frustrations with "waterfall planning". Enterprise SOA blends long term planning with tight iterations. Think, "planning in the large, agility in the small".



3. Governed Delivery over Ad-hoc Delivery
   The enterprise must prioritize the needs of the many over the needs of the few. Applications must be architected to fit into an ecosystem of applications. This will require adherence to guidelines and policies on technical standards and software processes, employed to protect the long term interests of the community.



4. Sharing and Reuse over Building from Scratch
   Portfolios of applications will have many common functional requirements. An implicit non-functional requirement in Enterprise SOA is to design for sharing and reuse where appropriate.



5. Business Priorities over the Enterprise SOA Manifesto
   I.T. systems are either a reflection of the business today or a projection of where the business is heading tomorrow. The I.T. approach must not become a religious battle fought at the expense of the business. On occasion, it will be in the best interest of the business to violate the principles of the Enterprise SOA Manifesto for the purpose of 'doing the right thing' for the business. Appropriate planning, governance and leadership should make this the exception, not the rule.
   

JackBe Closes $9.5 Million in Growth Funding

JackBe, a leading provider of mashup software, has closed on a new round of funding. This is a Series C round and should provide them the resources to continue building out their platform and sales engine.

I had the opportunity to speak with JackBe CEO, Luis Derechin, earlier this week. First, I have to publicly congratulate him on running (and finishing) his first marathon! I'm sure there are plenty of parallels to be drawn with running his business...

A couple interesting topics were discussed in our meeting. The first was the inevitable maturation of the market from widgets to platforms. Like many RIA vendors, JackBe initially focused on AJAX widgets and presentation layer accessories. Their business has grown into server-side mashup engines capable of integrating data from a variety of sources (databases, legacy systems, Web Services, etc.) and transforming the transports, payloads and data into easy-to-consume formats for Web 2.0 developers.

I believe that the mashup layer will quickly become an essential element in User Experience Reference Architectures (UE-RA's). The focus of older portal technologies is 'on-the glass integration'. Here, disparate data sources are pulled together as a set of portlets (or windows). Conversely, the Mashup Layer focuses on what I've been calling 'before-the-glass integration'. This enables new functionality to be inserted between consumers and providers (think clients and services), aimed at providing mediation and transformation services 'just in time' based on the context of the consumption.

Because this software is positioned squarely as a presentation layer-to-service go-between, it has the unique advantage of also enabling wide scale governance through policy visibility and control mechanisms. Think of it this way. Today we have 'mash-ups' tomorrow we'll have 'crash-ups'. Service interfaces will change, as will formats and protocols. This places new challenges on software configuration management and the overall governability of the Web 2.0 solutions.

We saw a similar trend in the SOA world where vendors who provided intermediaries had to make a decision. Are you the source of governance policies or the target? This is a fundamental question that each vendor will have to resolve. Said another way, will your tagline be "Mashup Governance" or "Mashup Enablement". That said, a key attribute of Mashup Enablement will be providing Policy Enforcement Points (PEP's), fed by governance vendors.

Over the last 5 years, many of us SOA-guys have put extensive thought into every aspect of the 'service provider' aspect, while neglecting the 'service consumer'. However, an acknowledgement that more advanced UE-RA's are needed will hopefully draw out other Enterprise Architects to surface a more in-depth discussion on this very important topic.

Quit the Clowning

Joe McKendrick is confused. In his latest blog post, "Enterprise SOA Concept Falls out of Favor", he implies that 'enterprise SOA is failing' which couldn't be farther from the truth. I believe that his bad information comes from people who don't know SOA, don't do SOA and in some cases, caused the mess that SOA cleans up.

In my position, I have visibility into HUNDREDS of SOA programs. Many are active clients - many are past - many are just companies that I've had the privilege to speak with. And through my partners, (the leading SOA infrastructure companies), I have excellent visibility into their historical sales and future demand pipeline. Between these vehicles, I am able to see commitments related to SOA strategy, training, governance, architecture, infrastructure, organizational design, change management, packaged application enablement, service integration and composite application development. That said, I feel like I'm in an excellent position to comment on what is really going on with regard to SOA.

First, SOA is nowhere near the mythical Gartner beast called, "The Trough of Disillusionment". And I think it's funny that people keep trying to force us in that phase so that we can then say we've moved past it. Nope. We're not even close.

Second, the idiots that are running around yelling "guerrilla SOA" have to be put in their place. Many of these individuals are the ones responsible for silo-oriented thinking in the first place. They proposed small (agile) projects where we captured just enough requirements to begin coding and releasing. Guess what? This style of development doesn't jive with the concept of shared services. It is the cause of the problem, not the solution.

We love to compare EA to city planning (plotting out neighborhoods, identifying common infrastructure, etc.) Yes - this requires using your brain and creating a plan. Enterprise SOA involves long term planning coupled with short term results.

Don't get me wrong - I'm a fan of 'controlled agile'. The rules of agile by themselves are so incredibly destructive to large organizations that they have done immense harm. Shouting 'agile manifesto' at people who have to build real 'application communities' is a non-starter.

I am proud of the companies that I work with who take the time to think about what SOA means to them. They plan their community. They consider the common infrastructure. They create policies and rules for their citizens. They identify practices to build the structures (reference architectures). And once they've figured out how to build a community they go do it. They don't do it for the entire enterprise all at once - that isn't what 'enterprise SOA' means. Instead, they partition their enterprise into a set of communities and attack them, often in parallel.

Let's be clear. Enterprise SOA is, by far, in the strongest position it has EVER been in. The jokers who feed columnists bad information need to go away. But this won't happen on its own - it requires the columnist to call them the clowns that they are.

Consolidation in the Software Industry

In June of 2003 I noted that, according to Yahoo Financials, Microsoft was larger than the next 40 largest software/service companies:

Quest Software, Inc. + Tibco Software, Inc. + Documentum, Inc. + Take-Two Interactive + Activision, Inc.+ Hyperion Solutions Corp. + Sybase, Inc. + Macromedia, Inc. + RealNetworks, Inc. + Business Objects + Cognizant Technology Sol. + Red Hat, Inc. + Satyam Computer + J.D. Edwards & Company + Autodesk, Inc. + CSK Corporation + Network Associates, Inc. + Konami Corporation + Compuware Corporation + Trend Micro Incorporated + Cognos Incorporated + Mercury Interactive Corp. + VeriSign, Inc. + Citrix Systems, Inc. + Cadence Design Systems + BMC Software, Inc. + Amdocs Limited + BEA Systems, Inc.+ Synopsys, Inc. + Siebel Systems, Inc. + Check Point Software Tech + PeopleSoft, Inc. + Infosys Technologies Ltd.+ Symantec Corporation + Adobe Systems Incorporate + Intuit Inc. + Electronic Arts Inc. + VERITAS Software Corp. + Computer Associates + SAP AG + Oracle Corporation

As I scanned this list, it occurred to me how many of them have been acquired...

1. Documentum --> EMC
   
2. Veritas --> Symantec
   
3. Hyperion Solutions --> Oracle
   
4. Macromedia --> Adobe
   
5. Business Objects --> SAP
   
6. J.D. Edwards --> PeopleSoft / Oracle
   
7. Network Associates --> McAffee
   
8. Mercury Interactive --> HP
   
9. BEA Systems --> ??TBD - Oracle??
   
10. Siebel --> Oracle
    
11. PeopleSoft --> Oracle
    

It is interesting to look at the list of companies that didn't get acquired. Let's remove the non-enterprise I.T. companies (entertainment software, semiconductor, consulting). The odd balls include: Sybase, Tibco, Cognos, Adobe, Citrix, BMC, Red Hat and Computer Associates. In my opinion, these companies need to find a home - and soon.

Companies that have had significant growth since my last post include:
VMware, Inc. and salesforce.com, however you should note that their PE's are 269xTTM and 1,245xTTM - and in my humble opinion - this is just a tad bit inflated! At some point these companies are going to have to increase their top line numbers. Regardless, we've entered into a period of massive consolidation where few new companies can truly shake the market.

SAP TechEd - We Have SOA (for real this time)

I've been attending the SAP TechEd in Las Vegas conference for the last few days. Overall, I'm impressed with the reality of the story that SAP has put together. In the past, SAP had a SOA-by-PowerPoint story. Today - they have real products and guidance.

At the core of the SAP SOA story is the Enterprise Service Repository (ESR). It is actually a combination of both registry and repository. The registry is a UDDI 3.0 implementation and has been tested to integrate with other registries such as Systinet. But the bulk of the work is in their repository. Unlike other commercial repositories, the first thing to notice is that SAP's is pre-populated (full, not empty). It contains gobs of information on global data types, schemas, wsdl's and similar artifacts relating to the SAP modules.

Both the registry and the repository are designed to embrace service metadata that is housed by SAP as well as service information that might be in other platforms (IBM, Microsoft, etc.) And although the registry will do metadata interchange with other registries, we're not so lucky with the repository. Apparently the current version is designed to be a single instance across the entire enterprise. Of course, this isn't realistic in most organizations due to mergers & acquisitions, etc.

SAP has also customized the TOGAF enterprise architecture to meet the needs of large customers. I was hoping to learn more on this but the speaker failed to show up (bummer). However, it was clear that SAP is relying on IDS Sheer to supply EA modeling tools.

I felt like SAP really got it. Unfortunately, I felt like most of the people at the conference didn't. The gap between vendor and customer has grown significantly. Many of the SAP customers have avoided technology topics, favoring black box implementations of large monolithic applications. SAP is introducing a fundamental change that will take time to sink in. They are doing a great job of evangelizing and providing community guidance but this is a huge leap for many of the 'ABAP' programmers of today.