SAP, IBM, Microsoft and Oracle

The 4 major enterprise ISV's have created their strategy. If you haven't been paying attention, I'll summarized it for you:

Microsoft - Microsoft will make the WS-* protocol ubiquitous by pushing them into the operating system. Then, they will provide unbelievable tooling (Visual Studio) and a firm foundation (Communication, Presentation, etc.). This strategy is developer focused, once again hoping to create an ecosystem of applications sitting on top of their platforms (Foundation, .Net core and Windows). How will these applications get funded? Most likely a combination of new VC money, MS funded entities and internal projects.

SAP - SAP has such a huge footprint inside of large enterprises that it makes it almost impossible to remove. SAP has to keep up with the trends: Provide an application platform (NetWeaver), service enable their system (ESA) and create an ecosystem (Xapps). Done, done and done. SAP has protected their market.

Oracle - Oracle looked like the dog in the group - until they bought out all of their competition. Less SAP, Oracle owns the application space. This means that they are concerned about the business services and processes. Does it matter if it runs on Oracle App Server or IBM WebSphere? No way. Everyone knows that the J2EE stack is commoditized - just ask JBoss. Oracle will use the WSDL as the new 'barrier to removal'.

IBM - At first glance it would appear as though IBM is the ultimate loser. They have lost the Application space to SAP and Oracle. Their WebSphere suite is commoditized which leaves them with two interesting items: Traditional IGS consulting and Business Process Outsourcing. From my view it appears that IBM wants BPO. They'll own your technology because they'll own your outsourced process.


Who wins?
This is a huge, huge gamble that IBM is taking. If BPO goes 'out of style', IBM will find themselves with no application strategy and playing second fiddle to the Microsoft tooling and platform. Ouch. On the other hand, if their bet plays out they will have the ultimate hand in deciding which vendors technology is used. Oracle has a massive integration project in front of them. SAP will find that it is hard to swap out the platform foundation for their ERP suite. Who wins? All of them - to some degree - no clear winner - all advance.

Who loses?
This is easy. Anyone that isn't SAP, Oracle, IBM or Microsoft loses. We aren't done consolidating so some additional companies will have interesting exits, but ultimately the consolidation favors the giants.

Should Stupid People Do SOA?

In not so many words, I found a piece that asks the question, "Should stupid people do SOA?":

"True story: A financial-services firm built an application to track risk management on a Web-services platform. What had once been one application was broken down into 15 XML-based services, some of which were outsourced because they encompassed noncritical information. It was a sound plan; by outsourcing some of the component services, the firm saved both time and money on the project. But there was one thing the developers hadn't considered, and that quickly became apparent when the application was deployed.

It was chaos. Instead of one application logging data, there were 15 services that needed to be managed--and all were sending messages to the system-management application. That app would in turn notify the IT department of the errors it was logging. Not only did the risk-management application crash, but it took the system-management application down with it, both of them overwhelmed by the essentially 15-fold amount of data generated. The company eventually had to redesign the way messages were handled to ensure that the system-management application only logged the most critical ones.

And that, in a nutshell, is the conundrum of combining a service-oriented architecture, in which loosely coupled business processes are transformed into discrete interfaces that can be easily plugged and unplugged as business conditions require, with the outsourcing of those business processes to third-party providers. The advantage is the disadvantage. You can break business processes down to their most granular, logical elements; focus your development efforts on where you can provide the most differentiation; and let someone else handle the overflow or the low-profit transactions. But you open yourself up to a management challenge the likes of which you've never seen."

Here's my view: Stupid people shouldn't do SOA (on-shore or off-shore). Stupid people shouldn't do object oriented. Stupid people shouldn't do ERP. Stupid people shouldn't have white-collared jobs... but they do.

In many ways nothing has changed. SOA doesn't keep stupid people from making smart mistakes or smart people from making stupid mistakes. It sure doesn't hide mistakes. In some ways it makes the mistakes more visible - which, if properly managed is good. I'd love to see the 'service oriented sequence diagrams' and the 'integration testing plan' for the aforementioned system. Any semi-competent architect should have seen the cross-cutting concerns and performed integration testing - SOA or otherwise.

SOA is an architecture that specifically leverages a continuum of talents: 'brains', 'average' and 'grunts'. Use the 'brains' to create the common services and practices and make the 'grunts' use them. Leverage the 'average' dudes to verify that the 'grunts' are doing things in alignment with the 'brains'. Done. Stupid people (grunts or not) always slow things down.

LINQ

If you haven't checked out the LINQ project from Microsoft, it is worth your while. Dealing with databases and XML documents has always been a pain in the rear. We have the constant mismatch that Hugh pointed out. Well, Hugh didn't get his new language - just a bit of pain relief.

Oh yea - also announced, Microsoft built a workflow engine that works off of state transitions. It only took them 30 years since their founding to build one. Woo hoo. If doesn't come with a set of WSDL's I'm going to be so pissed...

Extended Service Portfolio Management

A few months back I came across a great blog entry:

"At a fundamental level, the radical shift to SOA calls for a different mindset – a dramatically different one at that. The adoption of SOA shall signify itself to be an important development in the IT world. Software will be described as a portfolio of capabilities and possibilities instead of modularized applications. Data models will be standard-based and externalized to enable interworking between services, and data will be considered to be like any other form of "digital content" ever ready for exchange and transformation between systems."

Guys like Frank Martinez, Carlos Perez and John Udell have discussed the value of creating services whereby they may be recombined in a manner that was unintended at design time, 'unintended recombinants' if you like. Services were meant to be used, reused and reused in manners which the design never intended. Services that were designed correctly hold a special latent value - they hold the value of recomposition, both at design time and perhaps more importantly at runtime.

As large organizations perform Service Portfolio Management, they are beginning to notice that certain service designs enable reuse and recomposition. Nothing new here. However, as the service ecosystem begins to grow the Portfolio Manager will spend less time on their current 'service capability view' and more on the 'service possibility view'. Here, the goal is to evaluate opportunity.

The Service Portfolio Manager must become a specialist not only in enterprise refactoring but also in shopping and procurement. Services will be built, bought, leased and borrowed. Recombining services, from anywhere, for value-add solutions is at the heart of a Service Oriented Enterprise.

10 Low Profile SOA Comapnies

Here is a list of 10 SOA centric companies that fly a bit lower on the radar:

Redberri - Redberri Integration Platform helps enterprises to leverage the power of service oriented architecture (SOA) to streamline processes within a reliable, scalable and secure infrastructure.

GridScope - GridScope’s vision of Simply Managing Services™ is to provide a simple, dynamic solution for federated management of web services that underlie your enterprise-critical business processes.

FiveSight - FiveSight Technologies provides open source WS-BPEL-based business process execution and service orchestration products along with related support, training, and consulting services.

Xcalia - Xcalia makes SOA easy to implement with agile business intermediation software that combines heterogeneous data with services to rapidly develop and deploy transactional composite applications.

SOAPKnox - SoapKnox is developing products in the area of Web Services (SOAP) to ease developers in their development and deployment of Web services.

Above All Software - Above All Software provides business integration software that allows our customers to maximize the business value of their service-oriented architecture (SOA).

Cast Iron Systems - Cast Iron Systems is the inventor of the Application Router, a simple yet scalable integration appliance capable of connecting, transforming, and routing data and events from source to target systems.

GT Software - GT Software is a leading provider of enterprise application and data solutions that integrate mainframe data and applications into client/server and Web applications using ODBC, JDBC, J2EE and Web services.

Neon Systems - NEON's continued growth in the Web services market provides customers and prospective customers with the most robust set of solutions to support Service-Oriented Architectures (SOA).

Kenai Systems - Kenai eXamineXT provides One-Touch Vulnerability Assessment for Web Services.


Did I miss your company? Send me a note! jschneider at momentumsi dot com

IBM Ships ESB

IBM has announced that they have an ESB - and will be shipping it within the month.

Yesterday was a busy day talking with IBM personnel about the ESB and their new WebSphere Process Server. Naturally, I voiced a few concerns about calling it an ESB but if anyone can create a category, it is IBM.

What I heard was a couple interesting comments:
- Don't concern yourself with SOAP over MQ
- We agree, it isn't about JMS
- Don't worry about the protocols, we'll add'em in later

Hmm. If a WS-startup were to have told me this I would have gone off - however, this wasn't - it was IBM. Big blue customers will buy this. They will build on endpoints and mediate in the middle.

I remain disappointed in the lack of clarity around the ESB but am happy to see IBM put some new weight behind their SOA marketing. Congratulations to the IBM teams for getting these products out the door on schedule.

Our customers have been asking us for an ESB evaluators offering which is now available. Send an email to webservices@momentumsi.com. In addition, we'll be putting the IBM ESB into the MomentumSI SOA lab as soon as we can. We remain committed to pushing vendors towards the next generation of standards and pointing out those that are stuck in the J2EE world.

Pop Quiz: WebSphere was the IBM J2EE/Component brand; What is the IBM SOA brand?

It is time for WSEE

When I looked at open sourcing my stuff as part of an ESB - I quickly determined that the ESB had so many definitions (many of which didn't contain orchestration) - that the ESB had already crashed.

Modern software infrastructure is based on standards. Standards are grouped into profiles. Profiles are implemented and become products. I don't always like it - but that's the way it works. The ESB 'pick your standard' circus has demonstrated that our customers need more than marketing umbrellas.

We need architectural profiles.

The successor to the ESB MUST be profile based. Think RFC 2119.

What is an ESB?

MomentumSI's Definition of the ESB:

"An ESB is a collection of platform specific (Java) API's front-ending a vast subset of the Web service protocols, formats and identifiers."

---

---

---

---

I almost forgot - I've been meaning to congratulate Sonic on inventing 'SOAP over JMS', also known as the ESB. Unofficially, MomentumSI has been predicting that the bus would crash since October of 2003.

Here is the really sad news: ESB isn't dead as a category. It won't die until a replacement category is created. In my humble opinion, the ESB 2.0 won't work. What is the replacement: The Enterprise Service Network? Application Oriented Networking? I don't know. What I do know is that in an unprecedented display of incompetence Gartner & Sonic took a shotgun to the ESB category and blew it away.

Annrai, Frank, Dan, Roman - uhh... what the hell are you guys waiting for??? I'm going to start referring to you guys as the "Ball-less-four".

Open Source ESB - Apache Synapse

It appears as though the Apache ESB project, Synapse, is moving forward. According to InternetNews, Blue Titan, Infravio, WSO2, Sonic and Iona are all supporting it.

For those of you who aren't familiar with ESB's, Microsoft does a pretty good job of describing one in their position paper. They basically say that an ESB consists of:
- Orchestration & Transformation
- Intelligent Routing and Mediation

The heart of the current code base was donated by Infravio. However, it was quickly noted:

Sonic Software itself an ESB vendor (as well as an initial committer to the Synapse project) said that Synapse wasn't a full blown ESB. "This project is related to ESB , but it is not in itself an ESB," Dave Chappell, Sonic Software's VP and Chief Technology Evangelist told internetnews.com,. "What Synapse bring to the table is a mediation framework that allows users to get in the middle between service requesters and providers and perform various tasks – including transformation and routing and that helps to promote loose coupling between services "

So, if I understand Dave correctly - Synapse has the routing and mediation but not the orchestration and transformation. Sounds like a problem! Perhaps I can help?

As of today - I am open sourcing our Orchestration IDE, BPEL engine and Transformation system.



But what good is an open source ESB if you can't get decent support? None! Sounds like a job for MomentumSI.

Done. Stay tuned. More to come.

Mark Baker Hates Architecting First?

Mark, "I won't rest until you REST", Baker kicks a bit of sand on architecture first.

Oh stop it Mark - you architect first, too.

MomentumSI recently finished a large transactional web system for a customer. The customer was a startup - and had NOTHING. Guess what - before writing a bunch of code, we gave them a "Web Architecture"; we talked to them about the ilities (scalability, integrity, availability, maintainability, etc.) We recommended the infrastructure: firewalls, routers, load balancers, operating systems, web servers, web analytic engines, etc. We also recommended some design patterns and some platform choices (J2EE, IoC/PoJo, SOA-IoC/PoJo, .Net, etc.) Then we talked to them about implementations. My point is that these are things that the company didn't have - and needed before a SINGLE LINE OF CODE WAS WRITTEN.

If you're an organization that is going to do SOA - you should go through a very similar exercise. If you haven't answered the SOA infrastructure questions - or architectural configuration questions and you just start building services you'll end up in a mess. It isn't: "you may end up in a mess" or "you might end up in a mess" - it is "you WILL end up in a mess". Closing your eyes to up-front architecture is a bad idea in web systems, SOA systems or just about any system you can think of.

So, in summary:
YES - "Projects and enterprises should define their Service Architecture FIRST". If you're going to do service based systems - do it within a basic architecture. This doesn't mean go off and architect until you're blue in the face. It means lay down the basic architecture - we did it for web systems - we'll do it for SOA systems.

Tim Bray Supports WS-*

Via Nick Gall.

Tim Bray did an interview and has asked his readers to draw their own conclusion, which I have: Sun customers have had to invent their own distributed computing solutions - on their own dime - and have created proprietary solutions. AToM tried to tell them for years but had little luck.

Questions and Answers with RouteOne
Q: How did you do Routing / Addressing?
A: We went proprietary - because we had to.

Q: How did you do Reliability?
A: We went proprietary - because we had to.

Q: How did you do Orchestration?
A: We went proprietary - we can't wait to get off of it.

Q: Do you put anything standard in the header???
A: Yes, WS-Security

Q: How do you do messaging?
A: Vendor specific; ubiquity via platform API - not protocol

--------------------------------------------
Now it is possible that I misunderstood the point that Tim was trying to make... but if I read it correctly, he has a customer that wants protocol ubiquity. The customer has real problems (transactions, correlated messages, reliability concerns, security concerns, performance concerns). He had to roll his own protocols (boo) and stated that he could have gone faster if he didn't.

I'm so happy that Tim found an enterprise customer that had real issues. Perhaps with the acquisition of SeeBeyond Sun will become a WS-Shop ;-) Gee - having a few protocols implemented sure can change your tune!!!

The funny thing is that my friends at IBM and Microsoft NEVER talk about SOA specs anymore. That's so 2003. Perhaps we should debate JBI (or not).

Service Network Newsletter

The August edition of the Service Network Newsletter is available.


Enjoy.

SOA Boot Camp

After months of work, we're finally kicking off our SOA Boot Camp. MomentumSI consultants will be immersed in 17 days and nights of non-stop SOA education!

You name it - it made it: registries, repositories, governance, mediation, orchestration, composite applications, SO security, SO-BAM, legacy enablement, WS-I & WS-*, Indigo, Axis, SOBA, ESB, SOA reference architectures, SOA reference models, SOA process / methodology, SOA best practices, service analysis & design, XML message design, reuse metrics and more.

We have also signed up many of the leading SOA companies to provide vendor specific training on their best-of-breed products by their local gurus. After we run it internally a couple times we will be taking SOA Boot Camp to our customers.

SOA is a fundamentally different computing model - we've realized that the 2 and 3 day training just doesn't cut it. Let's hope that 17 gets the job done.

MS Composite App Strategy?

Web Services enable composition through lowest-common-denominator ubiquitous protocols.

Composite applications pull together Web services to fulfill some set of requirements. If you compile the services together (bake at 450 degrees), you'll find that the agile-controller isn't so agile.

So, all of this said... what is the Composite Application Strategy for Microsoft? All the work on Indigo was great, but where is my 'service join' facility, or my 'agile controller' - for that matter, where is my 'semantic adapter'?

From one perspective you could say that SDM represents a portion of the strategy - but it only reflects the 'service oriented bill of materials'. BizTalk? Wow - I hope not... any insight?

If you're not familiar with 'composite applications platforms', take a look at:
http://www.cordys.com
and
http://www.aboveallsoftware.com

Hacktivity Level

The 'hacktivity level' is way up. Casual services, dynamic scripting and remixing are clearly the theme for 2005. JSON, POX, REST, RSS, etc. have taken hold - they've intersected with client-side contextual applications like Google Maps to create what some people would have called a composite application - you may prefer the terms remix or mash-up. Even Business Week is taking notice.

SOAP & WS-* have turned into the stiff-collared, corporate world, slow to move technologies. Once again, our passionate technology community is breaking all the rules and creating compelling applications - and I love it.

Hacker - 'I need that service and that other service. I need to combine them. I need a server-side aggregation engine. I need to re-serve the combined service. I wonder who will enrich/transform my service? Who cares. I need a client-side visualization mechanism. It has to have easy API's that front-end the data services. Damn this is cool. Interesting - it looks like a 'web of services'. Clients. I need contextual pivoting - Maps - Austin - Concert Halls - Concerts - Reviews - Tickets - Buy - Receipt - Calendar.'

CIO - "Did you see what some hacker did with concert reservations? Can we provide our core services to the outside world? Wait - can we consume other peoples services and create our own application out of them??" - Why yes.

The World Wide Web is turning into the Service Oriented Web. The technologies will be stiff and flimsy; the artists will be straight-laced and no-laced. The intersection will be magnificent; the Web is reborn. The SOAP/WS "transactional web" will be a portion of the new SOW, perhaps a small portion. Our future will be driven by those who have the passion and desire to create it.

Hey Don Box,

All of us in the SOA blogosphere have appreciated your input and insight. However it has come to my attention that Microsoft isn't practicing what they're preaching. I'm hoping that you can tell me that my information is dead wrong.

I ask one simple favor. Start blogging about how Microsoft is using SOA internally. I've been told that Microsoft spends more money on SOA evangelists than they do on building SOA solutions internally.

I'll extend this challenge to every single Microsoft blogger. Don't tell me about your latest spec or library - tell me how Microsoft uses it internally. The Microsoft I.T. department should become the SOA showcase.

Respectfully Submitted,
Jeff

I, Too, Have Seen the Enemy

Charles Garry comments, "I Have Seen the Enemy and It Is Complexity". He writes,

"Web services is yet another example of potential complexity headed your way." ... "I have perused a number of books on the subject, but the one thing I never see discussed is how one makes a virtual application highly available. What are the implications for backup and recovery of data? How do we manage security permissions and authorizations? Clearly, with the added flexibility, we have also created a new set of obstacles to overcome."

He goes on to state:

I suspect we will continue to see a growing trend towards infrastructure rationalization (fewer kinds of things) and consolidation (fewer numbers of things) as a means to reduce complexity. This trend is both useful and necessary if we have any hope of utilizing some of these new computing paradigms.

Charles believes that Web services increases complexity. By no stretch of the imagination do I consider myself an expert in complexity, chaos, systemics or related concepts. However, I believe that the conclusion Charles reaches is incorrect.

His assumption is that we are adding new elements to a set - and as the set grows, so does the complexity of the set. His answer is to reduce the number of elements (rationalization and consolidation) and this is where we differ.

Enterprise software is going through a 'specialization' and 'externalization' movement. We are taking pieces of code that seemed unique and abstracting them into reusable concepts. We do this with design patterns, architectural patterns, domain specific languages, platforms, libraries and specialized engines. Each time we see these reusable items, we 'write them down' (or externalize them). The complexity in the system already existed; we merely found the pattern, factored out the common substrate and documented it. Externalization is a well-known mechanism for reducing complexity; you take that which was not understood and make it understood.

As we take our mountains of unintelligible 3GL code and move much of it into common infrastructure, we increase the amount of 'known' computing elements and decrease the amount of 'unknown'. This process has an odd effect. As the inventory of known elements grows so does the concern for 'having too much'. This leads to a human fear of 'large-set-complexity'. And the natural reaction is, yes - you guessed it, rationalization and consolidation. This is a human tendency whereby man attempts to diminish complexity by hiding it. We take those First Order computing elements that made our inventory list and reduce them back into 2nd order elements, thus removing them from our list. And somehow, we feel better that we defeated the enemy.

Specialization of vocabularies, models and elements is a natural progression of every science. However, specialization must be followed with abstractions, taxonomies and containment. In essence, we must not hide our new found computational elements, rather we must manage them.

Web services are an additional element to our computing infrastructure. From one vantage you can claim that they are just another element to the set increasing the complexity. However, Web services will help to reduce systems complexity by adding a new abstraction over our computing environment. Although the total number of elements increases, we find ourselves commoditizing those lower in the stack and working with those that are closer to the business value.

The enemy of SOA isn't complexity; it is a lack of understanding. We must not retreat from our sophisticated computing infrastructure. Instead we must use cost effective means to manage the piece-parts, identify the abstractions, create common groupings and externalize the system.

Crush My Head Like an Acorn

Sean McGrath has suggested that the Reed's Proposition may be closer than Metcalfe's Law in describing a theoretical upper limit value function on a Servcie Network.

For those of you who haven't had the pleasure of meeting Sean, his physical presence reminds me of the "boulder thrower" on Braveheart:



I firmly believe that Sean could crush my head like an acorn with his bare hands. Hence, I'll be careful to disagree with him.

Acorns and noggins aside, as usual Sean makes a great point. Metcalfe's law is an over-simplification of a complex formula. In my humble opinion, so is Reed's.

My goal is simple - I want the enterprise to begin looking at their services as a network and determining the value function that works for them. Today, virtually no formulas are applied.

It is true that some services will provide more value than others. And some business processes are fundamentally more important to competitive advantage than others. Services that support key processes will provide greater value. We will also see that 'service gaps' will destroy the value of 'process networks', suggesting that some services only have value when bundled with other complementary services in the same value chain.

Value chains are created around: customers, suppliers, products, employees, etc. We create networks that link these entities using various levels of constraints. Those links which require minimal constraints are usually deployed first and are the most free-flowing and collaborative in nature. From a computing perspective these entities will be joined via well known networks including WWW and RSS. The value of low-constraint, high collaboration networks is well known.

As we increase the level of constraints and diminish the ease of creating self-forming networks due to semantic mismatches, protocol impedance or the mandate to fulfill non-functional requirements, we find ourselves creating services with a lower ROI. This isn't because the "R" (return) has changed; it is because the "I" (investment) has changed.

Enterprise Service Networks will not produce an adequate ROI if they are not able to reduce the 'service drag', lowering the investment. That is, it is the burden of the enterprise to employ 'service oriented infrastructure' that facilitates rapid service creation and composition by removing the aforementioned obstacles. In essence, the value function must look forward in time, forecasting a future value of the network, less the 'drag' related to adding clients and services. This is what I call the AOL Argument; fundamentally the Web created a more fertile environment for adding content to a network than did AOL.

Corporations use valuations that are forward looking vehicles (DCF, EVA, etc.) I would argue that the value of the network is less of a snapshot in time but rather a forward looking forecast based on the potential growth of the network as it directly relates to the value chain of an organization. I view the Metcalfe/Reed concepts as an easy way to introduce I.T. personnel to network valuations. However, due to their inability to capture forward looking results and correlate node-to-value concepts, they both remain inadequate at best.

Please don't crush my head like an acorn ;-)

The Value of the Service Network

Just a quick reminder...



We aren't just building Web services.

We aren't just creating an SOA.

We are building a network of business services.


We must also remember that it takes MORE work to create VALUABLE services.

Sun's Big Year - 2186

Based on historical performance of SeeBeyond (income statement), and including new synergies (sales force, engineering), I estimate that Sun should break even on their $387,000,000 cash investment in the year 2186. I realize that it is tough to wait 181 years for the ROI to kick in - but I'm sure Scott (and his great grandchildren) will be patient - as will Wall Street.

I wish Sun the best of luck getting JBI adopted.

I should mention to the M&A crew at Sun - - I heard a hot rumor! A COBOL company is up for sale!! Time for JSR 38,940 - JCOBOL! You'll make BILLIONS!