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.

Which IBM ESB?

IBM has been beaten up by the press and blogging community for having two ESB's. Here's how I look at it. One is for new customers and new installations (WebSphere ESB) and one is for the legacy upgrade path.

Google Flow and Goolge Forms

I believe it was 1994 - maybe 1995 when I last talked with Eric Schmidt. I asked him a very direct question, "What is the killer app for the Web?" and he responded, "Groupware". Perhaps that was the Novell corporate line - but honestly, I think he believed it. For those who don't remember - Groupware was a term that involved electronic forms and workflow/collaboration.

I've been reading about Google becoming a business computing platform. If Google wants to be a business computing platform, they need two things:

flow.google.com
forms.google.com

Of course, this moves them from 'unstructured' data to 'structured' - and implies that Google attacks the identity / role problem. But let's get real - most business systems capture data, store it, aggregate it and redistribute it. During the process we monitor it and report on exceptions.

The world has been waiting for a clean simple way to do these common tasks. Google is in an excellent position to enable business 'Software as a Service'. The traditional problem with this approach has been accessing the data once your 'SaaS' provider collects it. Well, Google clearly understands that SOA and Web services provide a real nice vehicle for facilitating data transfers.

Come on Google - make my day.

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.