Busting the UBR Revisionists

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

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

And I quote from the Microsoft UDDI site:

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

Or do you prefer this one:

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

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

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

Some Past Predictions...

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

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

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


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

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

Obsolescing J2EE

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

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

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

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


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

Is REST Needed?

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



He goes on to state:



and the follows it up with several slides like this:


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

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

Bye Bye MS UBR!

Just received this email:

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

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

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

Thank You,
Microsoft UDDI Team

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

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

Mr. Don Box,

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

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

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

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

Respectfully submitted,
Jeff

SCA and Location Coupling

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

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

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

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


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

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

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

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

Refabricating Architecture

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

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

Authors, Kieran and Timberlake, go on to state:

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

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

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

I Hid the Turd

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

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

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

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

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

Sincerely,
Your Entire Staff

Requirements & Specifications in Service Oriented Systems

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

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

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

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

---

Course Outline

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

---

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

The SOA Ecosystem

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

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

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

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

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

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

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

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

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

Judith Hurwitz on SOA

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

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


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

Agreed.

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

Agreed.

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

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

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

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

SOA requires a container that creates a composite application.

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

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

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

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

I guess... :-)

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

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

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

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

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

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

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

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

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

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

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

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

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

SOA Soldiers Wanted - the weak need not apply.

SOA Boot Camp: Day 13

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



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

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



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

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

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

SOA Boot Camp: Days 10, 11 & 12

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

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

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

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

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

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

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

SOA Boot Camp: Days 8 & 9

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



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

SOA Boot Camp: Days 6 & 7

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


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

SOA Boot Camp: Days 4 & 5

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

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

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

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

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

SOA Boot Camp: Day 3

Another tough SOA Boot Camp Day!


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

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


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

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

SOA Boot Camp: Day 2

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

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

SOA Boot Camp: Day 1

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

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

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

Dear CIO, I Can See Your Underwear!

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

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

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

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

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

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

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.

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!

The Service Network - July 2005

Our July edition of The Service Network is available.

And yes, the favorite line seems to be:

"SOMA (Service Oriented Modeling and Architecture) –Vaporware or IBM Global Services with a copy of Visio?"

When will SOA take off?

In 135 days.

Seriously - the Web service and SOA era will begin in 135 days.

176 I.T. Jobs Posted in USA

In the last 24 hours, 176 I.T. and software related jobs were posted on Monster.com...

I was curious how many were posted in India however it was difficult to tell. Even when limiting the search engine to only return jobs posted in the last 24 hours, the number posted exceeded the limit. I attempted to further tune the search criteria but was still hitting limits.

My best guess is that in the last 24 hours approximately 3,000 to 4,000 jobs were posted on Monster.com for India.

After sampling the job descriptions, it appears as though approximately 70% of the jobs posted in India were designated to fill U.S. demand. If this math is correct, that means that for every software job requirement that is posted in the United States, fourteen are posted in India to fill the same U.S. demand.

AToM: Sun Needs to Learn From Microsoft

We have a clear winner in the quote of the month category:

Anne Thomas Manes, a Boston-based analyst with Burton Group Inc., echoed those sentiments.

"What bothers me is that I really don't like JAX-WS," Manes said. "The Sun JAX-WS team really needs to learn a few things from Microsoft. They should be building something like Indigo—a common programming model that encompasses JAX-WS/JAXM, JMS, RMI and EJB. But Sun doesn't get that."

Can someone please send me the name of the person at Sun who is responsible for this? (Yes, I'm still interested in seeing prediction #7 of 2004 come true... how sad.)

The WSDL is the Offshore Contract

As more and more organizations move large portions of their I.T. department to offshore facilities they are questioning which activities to keep on-shore and which to push offshore.

For those that have chosen a service oriented path, the decision seems to be clear: "The WSDL is the Offshore Contract". In other words, domestic employees will work on business processes, enterprise architecture, orchestrations (agile controllers) and service design (up to the WSDL). And building the service? You got it - offshore.

It's an interesting line to draw, yet perhaps an obvious one. Using the "software contract" as the "legal contract" invites a clean division of labor and facilitates a simple approach for acceptance testing.

Obviously - the WSDL only defines the external interface leaving other aspects of the service (LIKE THE INTERNALS) to be described by other mechanisms. The algorithms and business logic are described with variations of the Use Case (think 'service case'). The relationship between the server and other elements (the hosting container, other services it calls, etc.) will likely be described by the System Definition Model, or some variation.

The science of describing architectures, interfaces and dependencies has significantly increased in recent years and it appears as though we are entering an era where the adoption level will skyrocket. The ability to describe systems in this fashion is what I've been calling 'precision specifications'. By using digital definition languages like SDM and WSDL, we are able to provide a 'software factory' with clear directions for construction.

Using 'services' as the unit of work appears to be a very manageable approach. Companies that are big into test-driven development will likely find test-driven-services a natural extension. Organizations that have adopted the Agile Manifesto may find this world too rigid. However, the Extreme Programmers may like the ability to lump X number of services into an iteration plan. And project managers will be thrilled to see acceptance tests directly linked back to line items on the Gantt chart.

I.T. organizations must increase their capability to describe systems with precision specifications prior to initiating a 'SOA factory'.

CIO's Aren't Taking SOA Serious

I'm going to make a quick prediction:

More CIO's will lose their job over SOA implementations than lost their job over ERP implementations.

---

I was chatting with a CIO the other day and asked him, "In retrospect, do you think you were involved enough in the early stages of your ERP implementation?"

He answered, "In retrospect - no - I wasn't involved enough. Had I known the size of it I would have definitely gotten more involved."

I followed up with, "Are you aware that an enterprise SOA roll-out will be significantly larger than your ERP implementation?"

He started laughing; he thought I was joking. My face didn't change. He quit laughing. "Jeff, are you serious?"

"Yes, I'm very serious. SOA is a complete overhaul impacting how systems are analyzed, designed, built, integrated and managed. And not just some systems - all systems including packaged applications like ERP."

He responded, "But with ERP, it was an all-or-nothing approach. Doesn't SOA offer an incremental approach - one that can be managed better?"

"Yes and No", I responded - "SOA is first and foremost about a network of services. The value of your service network is directly related to the effort of creating/obtaining services and making them available. All networks require a critical mass of 'valuable services' before they become useful to the consumers. The SOA service network is no exception. What I'm saying is that you can take a slow and steady approach to SOA but be prepared to receive gains that are even slower. Remember - this is really about the 'network effect'.

SOA done properly is a massive undertaking. It requires a rethinking of your infrastructure, development methodology, business impact analysis, budgeting process, organizational design... Don't underestimate the value it provides, the competitive advantage one can assume AND the investment it will take!"

It was clear that I had surprised my friend - perhaps even scared him a bit. And I realized that so many of the people in this space (vendors, analysts, press) are doing a disservice to the CIO by failing to tell the whole story: An Enterprise SOA implementation will be larger than ERP, Y2K and the Web.

Now is the time to get involved.

SOA Training!

For the last couple years we've been training people in SOA and Web service technologies. Recently, we've added a couple courses including "SOA for Architects" and "SOA for Managers" - both excellent.

See:
http://www.momentumsi.com/services/training.html

I'd love to do a course on buidling your SOA Reference Model...

Hiring SOA Consultants...

Momentum is opening up new positions for SOA consultants. All positions are travel intensive and require a strong background in distributed computing and enterprise architecture. Interested candidates should send Melissa a note: careers@momentumsi.com

We're basing the consultants in one of three delivery centers:
- Austin / Dallas, Texas
- Reston / Washington D.C.
- San Francisco / Silicon Valley
------------------------------------------------------

The Service Architect
At Momentum, the Service Architect is responsible for analyzing architectural requirements and translating into service based solutions. The architect will work with various existing architectural styles (monolithic, client/server, 3-tiered) and modify those systems to accommodate a service based approach. The architect will also be responsible for identifying SOA based solutions to the non-functional requirements (security, transactional integrity, reliability, availability, agility, etc.) Lastly, the Service architect will be instrumental in creating Software Architecture Documents, identifying components, estimating time-to-transition, providing guidance to designers and developers and linking architectural investments back to financial returns.


Requirements:

The SOA Architect must be well versed in Enterprise Architecture, Service Oriented Architecture (SOA), J2EE and or .NET Architecture.
Full life-cycle implementation experience (requirements, design, implementation, integration, testing).
Experience designing and implementing n-tiered application architectures.
Fluency in first generation web services standards, technologies and tools (e.g., XML, SOAP, WSDL, UDDI, BPEL, etc.).
A strong distributed computing background is a requirement (CORBA, RPC, DCE, DCOM, RMI).
Familiarity with messaging systems is a plus (Tibco, WebMethods, MQ, SeeBeyond).
Familiarity with commercial Web service products is a plus (Systinet, Blue Titan, etc.).
Knowledgeable on WS-* standards.

Other:

• Strong interpersonal, strategic oriented thinking and excellent written and verbal skills are essential.
  
• Ability to present professionally and persuasively to C-level executives.
  
• A minimum of 10 years experience overall in software development.
  
• A degree in Computer Science is preferred.
  
• Travel is required for this position.
  

About MomentumSI
MomentumSI is a pioneer in service oriented architecture, integration, and application development. Since 1997, the company has built a reputation as a leader in architecting large scale distributed computing solutions for IT organizations. Today, MomentumSI is at the forefront of service oriented architecture and integration for enterprises. We built the first Web service orchestration server for .NET and have been an active member of Web services standards groups, such as OASIS. Momentum continues to invest our SOA practice and is looking for the best of the best to join us.

Entire Software Sector up on Web Services!

Now this is interesting:

NEW YORK (MarketWatch) -- Goldman Sachs raised its rating on the software sector to attractive from neutral on the belief that the emergence of Web services architecture will accelerate industry growth and on expectations that share prices will rise as investors position for an anticipated year-end rally. Analyst Rick Sherlund believes a movement to a new generation of Web services base standards, which will result in more flexible and adaptable systems that can allow for changes in business processes, could reinvigorate growth for information technology vendors. He said the Phase I adoption of infrastructure software from IBM , BEA Systems , Oracle and Microsoft to enable the new standards is well underway, and the Phase II re-architecting of existing applications from SAP , Siebel and others is upcoming. He said Phase III will be integrating the new standard into desktop systems, which should stimulate a replacement cycle. Sherlund recommends positioning in the expected leaders of the next generation systems, even if the benefits aren't expected for a few years, given attractive valuation and the anticipation of a typical year-end rally.

See: http://biz.yahoo.com/cbsmb/050523/390440d059074e4881ce4b5a86c54332.html?.v=1

Increasing Reach

Software reuse has always had issues. In my opinion, the most common types of reuse are:
1. "Copy & Paste Reuse".
2. Off-The-Shelf Reuse - Here, we leverage JVM's, .Net API's, J2EE libraries, open source offerings, etc. that are pre-built and providing immediate value.

The third (and elusive) category would be the homegrown libraries - often domain specific. Let's be clear - the more general the problem, the easier to reuse; conversely, the more specific the problem, the harder to reuse. The easy stuff is packaged in your favorite off-the-shelf library - leaving the more difficult stuff for the I.T. department.

Reuse is difficult - and reuse via language specific code snippets is often easy but fails to scale and provide real value. Reuse via off-the-shelf packages is great - but in many organizations - this one has already been tapped. This brings us to Reuse Through Reference.

Services are a great mechanism for providing reuse through reference - however, many people seem to forget one simple item: REACH.

Reach describes the 'reusability potential'. Imagine having 10 systems 9 of which were in COBOL mainframe apps and the 10th was a .Net application. Let's state that the COBOL applications don't have the ability to access the native services provided by the .Net application, but do have the ability to talk Web services. Interesting - I just stated that it can speak "Web services" - does that mean WS-I basic profile? Which other WS specs does that include?

In an attempt to increase reuse through reference, we (the enterprise architects) are finding the need to increase reach. This means that we must identify protocol ubiquity levels within our organizations and quickly create critical mass.

Generally speaking there are two methods for increasing the reach:
1. Modify the connector capabilities at the endpoints (COBOL apps, etc.) via service enablement (WS-PaintJob)
2. Provide protocol mediation/translation in the network.

WS-PaintJobs are an easy way to black box systems and increase reach. However, the total number of protocol permutations between any given client and any given service grows exponentially with the size of the service network. This leads to the realization that a protocol mediation strategy is not only useful but mandatory.