|Service Oriented Enterprise
Saturday, September 17, 2005
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.
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. posted by jeff | 11:05 AM
Friday, September 16, 2005
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... posted by jeff | 4:14 PM
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. posted by jeff | 10:34 AM
Wednesday, September 14, 2005
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 posted by jeff | 4:57 AM
Monday, September 12, 2005
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 firstname.lastname@example.org. 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? posted by jeff | 10:53 PM
Sunday, September 11, 2005
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. posted by jeff | 7:19 AM
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". posted by jeff | 6:39 AM