There’s a lot of points that will be made in this blog entry.  To keep them straight, I will highlight them right up front:

• Vendors are getting behind SCA because it reinforces a need for tools
• The importance of architects in software development
• Untested technologies are being pushed on IT like bad drugs from the FDA

So, in this morning’s email I received a notification from ActiveVOS that their CTO is a primary contributor to a new book recently released on Service Component Architecture (SCA).  Having just recently completed a full investigation into SCA, two things jumped out at me: 1) SCA is heavily being driven by the vendor community and 2) SCA breaks many of the rules of SOA that have been touted by these same vendors for the past 6 years.  For example, SCA rewards an implied contract versus a contract-first approach to service development.  That is, the contract is derived from the programming model versus defined by the architects.

What’s going on here?

My subjective opinion based on all the factors that I currently have at my disposal is that SCA is a step backwards in software engineering.  It’s an abandonment of the SOA principles that have failed because of lack of investment in proper architecture toward a pure programming model driven by software engineers.  Thus, the goal here is once again to allow poorly-designed systems to be built by software engineers with very little architecture experience so they can claim to have some attributes of SOA.  Moreover, SCA is heavily dependent upon tools for creation and management.  This is a game-changer from applications that be developed with a good ‘ole EMACS editor and a command-line compiler.  Starting to get the picture?

I recently was sent an email by a software engineer on one of my projects claiming that based on their experiences over the past year with J2EE and BPEL that this is the way that they would build all their applications.  Unfortunately, the requirements for the application they’re on call for pure workflow management, not integration.  Which leads me to my next point, all software needs to be properly designed by an architect.  Software engineers build, architects design.  Architects should have a much wider berth of experience implementing and supporting various solutions using various technologies in a multitude of environments.  Having accomplished the latter, one learns the reality of taking any concept from paper to production.  Unfortunately, in many organizations, the developers are not forced to participate in operational support and are never privy to the impact of their bad decisions.

Additionally, tools vendors are blurring the line between form and function of various technologies and standards.  BPEL is a great example.  First off, BPEL 1.0 barely supported a plausible B2B integration scenario, and now BPEL 2.0, barely out of the starting gate, is the uber platform for all BPM, SOI, Integration and workflow?  Come on, let’s use our heads here.  At best, this standard is in its infancy and hardly appropriate for development and delivery of production systems.  Still, we have pundits discussing how XPDL lost the battle to BPEL (http://itredux.com/2008/09/28/why-bpel/), which is a bold claim considering the WfMC is currently working on BPMN into XPDL compliance.  Then we give this information to software engineers and ask them to make architecture decisions based on it and we wonder why the CEO thinks IT is a bunch of backwards yahoos and the Cloud and outsourcing looks like the answer out of dumbass alley.

Finally, and this distresses me the most, we have a growing number of software engineers, like the one I discussed earlier, that become entrenched in understanding how to work with these tools and technologies, become ideological about them and reject alternative methods and approaches to the detriment of the software and solutions they are building.  What’s more is that these software engineers work to undermine alternative opinions and slur engineers and architects who do not agree with this approach.   For the past few years, we have seen this with Spring and Hibernate, and will begin to see this more and more as BPEL and SCA gain  in momentum as pushed by the vendors.  Perhaps the reason Microsoft has never been threatened by the Java community is that they can see these vendors and engineers are cannibalizing each other through layers of complexity to the point where Microsoft’s .NET simplicity looks attractive.

If I Was An IT Manager I Would…

So, if I was an IT Manager, Chief Architect, CIO, CTO for a mid- to large-sized business today, here’s the things that would be on my checklist to ensure that the systems that I was building today were maintainable, sustainable and reliable:

1.  Enterprise architecture – I would ensure that all applications in my portfolio were being rationalized with the needs of the business as a whole and not a single group of users.  The latter is a bottom-up tactical approach that eats at the IT budget and limits the ability to design for the needs of the business as a whole.  While they are difficult to avoid building, they act like parasites sucking the IT budget from a support and maintenance perspective limiting the opportunity to build software that will propel the business forward.

2.  Chief Architect – I would put a single solution architect in charge of all the software that is being built.  This person would rationalize the product and tools being used based on reliable, tested technologies, not the latest fad.  This person would also provide objective, not ideological direction with regard to technology selection.  Many businesses today are still asking Java vs. .NET.  The reason for this is that .NET offers some very powerful solutions and allows for rapid application development that can be deployed on Linux boxes using Mono if that is desirable.  However, the Java bigots aren’t really open to having their skills made invalid by selection of C# and .NET platform.  It’s like offering a natural, homeopathic cure in the face of a big pharmaceutical company or a cross in the face of a vampire; these things cause mortal wounds, hence, you cannot allow them to control the choice.

3. Get the vendors out your organization.  A recent blog entry by the CEO of WSO2 listed the current Oracle suite in the gigabytes, this is not expressing the virtues of KISS.  Vendors’ product suites are bloated, costly and in many ways proprietary.  Developing distributed systems is complex, but can be made simpler by reducing the number of moving parts.  The number of artifacts required to develop a SCA application is double to triple compared to the number of artifacts to create the same application using SpringWS.  A properly-designed SOA reduces complexity, while these supposed SOA tools increase complexity significantly.  Vendors know you are desperate for resources and will take advantage of this fact today ultimately locking you into a product selection that will be extremely costly to back out of in the future.

In Conclusion

Ultimately, the rubber needs to meet the road, and work needs to get done.  The recommendations I make above are subject to the biases of the individuals and their experiences, but this too can be mitigated (to a degree).  The CAEAP has an oath of professional conduct that if adhered to by the professional will lead to the best decision, even if that decision is not the preferred one of the architect.  IT resources–specifically engineers and programmers–make their living based on their skills; the more their skills are in demand the greater the value and the more money that can be earned.  Businesses would do well to stop hiring resources based on individual technology skills (except if you’re hiring a consultant, because that’s what you’re buying) and start hiring based on the individual’s ability to think your business to success.

Years ago, mid-80’s, when I was interviewing for positions, businesses used to take pride in testing how programmers thought about problem solving, today, they look for buzzwords.  Which brings us back to SCA.  It won’t be long till these three letters start showing up on resumes.  Will your organization succumb to the pressure to use a tools-oriented approach to developing inferior networked applications that will need to redesigned and redeveloped in a few years, or will you avoid the peer-pressure sand trap this time and continue working toward a properly designed solution that will carry your company forward?