Monthly Archives: July 2009

When SOA Fails, Just SCA

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?

Sun Was Too Arrogant To Survive

Sure, now that the deed is done and the board has approved the acquisition, there’s lots of Monday morning quarterbacks.  However, in this case, I’m not one of them.  Indeed, I point to the release of my 9/1997 report that I wrote for NC.Focus entitled “State of Java Report: IBM” and the subsequent press release where I assert that IBM is leading in deploying Java in the Enterprise.

The story goes somewhat like this.  On the day I released the report, I subsequently released the press release through PR Newswire, but it was also available on the IBM website.  Within hours of posting the press release, IBM was contacted by Sun and told to remove the link to the press release on their website.  Ultimately, Sun did not like the fact that I presented that IBM was doing a better job of monetizing Java in the Enterprise than Sun was, but that was the truth.

Now, Sun had some great hardware solutions; especially in storage, so not monetizing Java was not the only cause for their downfall, but I believe it was a primary cause for Sun’s eventual demise.  My example is just one of my many interactions with Sun during my time as an analyst that demonstrated to me that Sun’s arrogance regarding their inability to understand how to monetize Java.  I worked closely with Sun’s development tools group, who had a series of failed attempts getting businesses to adopt their development tools.  This is in contrast to IBM, who’s WebSphere tools are spreading like a bad virus through the industry.

I believe had Sun been less arrogant and more open to seeking ways to better monetize Java, they’d still be a viable going concern today.

The Impact of Making Product Choices Using Qualitative vs. Quantitative Analysis

As part of my job, I help customers to select the appropriate software to either fulfill a need or as a component of a larger solution.  Fulfilling this role means comparing similar software offerings and selecting the best fit.  The challenge in this goal is to map the vendor offering into a subjective requirement, such as “best fit”.

Throughout my career I have acted in the role of consultant, architect and analyst.  In each role, I have had the same challenge of identifying the best in particular product category.  As a consultant/architect, the selection criteria was based on either an enterprise need or a single solution need.  As an analyst, the challenge was a bit more difficult because the criteria was based on being a solution to a problem domain.

Ultimately, comparing and scoring different products can take two approaches: qualitative and quantitative.  Both can be useful depending upon what you are looking to achieve.  I have found that I prefer to be a qualitative analyst than a quantitative one because in most cases I find ratings useless and arbitrary, whereas a qualitative answer illustrates depth of reasoning for a particular outcome.

I once walked away from an assignment because the research firm wanted me to quantitatively compare CORBA, DCOM and RMI as distributed object computing frameworks.   As much as I tried to explain, that they all have equal merit, the ultimate decision if one is better than the other is the environmental factors, not the individual technology.  Unfortunately, that fell on deaf ears in a firm grounded in scaling each feature 1 – 10.

With regard to qualitative and quantitative analysis of particular products, it gets even more interesting when you start to get the vendors involved.  A quantitative matrix usually entails requesting if a product supports a particular piece of functionality.  For example, do you support LDAP.  Having worked for multiple software vendors, I can tell you filling out these questionnaires by analyst groups can be an entertaining activity.  While certain features are straightforward, there were plenty where the answers got as interesting as, “yeah, if we hang Jim out the 3rd story window on a windy day, while he’s scratching his a$$, I think it we could do X.”  Hence, the resulting set of answers tells you if a vendor’s product has a certain level of completeness, but it doesn’t go into enough qualitative depth to decipher if the implementation is any good.  Moreover, even if the implementation is good, does it fit the purpose for which it will be applied?

An additional benefit of doing qualitative analysis over quantitative, and one that is critical to product vendors, is that you can truly identify where products are differentiated.  For example, many of the SOA platforms out there today, on the surface, all seem to provide similar functionality.  What really differentiates them is intangible’s, such as how much training is required for a developer to be productive or how easily can you build and deploy a service.  Quantitatively, IBM’s WebSphere’s platform clearly wins time and time again when comparing SOA platforms on completeness, but if one explores how much training is required and how many steps are required to build and deploy a simple Hello World service, the simplicity of a Spring Web Services container becomes more attractive.

Ultimately, I believe that this divide is central in IT failures.  Products are selected based on the wrong criteria.  Products that are selected quantitatively, may not be the right product for a given environment.  IT groups that go outside the “popular” choice and leader quadrant on the Gartner reports and look at how a particular product supports their specific needs for a given solution are often more successful.  Additionally, while not popular due to how it increases product proliferation, businesses will be more successful if they stop overloading their product selections with Enterprise requirements and select their product more tactically.  While this seemingly hurts the pocketbook, the losses in productivity and inefficiency–which is often not managed and, hence, difficult to compute–will outweigh the licensing and product management issues.

Then What Does Make Someone an Architect?

So, allow me to expand on my prior blog entry — Architecture Frameworks Don’t Make Architects — and answer the question, what does make an architect?

To help structure my query, I went in search of a concrete specification that defines the difference between and engineer and an architect and found this http://www.pels.ca.gov/pubs/building_design_auth.pdf

STRUCTURAL ENGINEERS may design any building of any type.
CIVIL ENGINEERS may design any building of any type EXCEPT public schools and hospitals.
ARCHITECTS may design any building of any type EXCEPT the structural portion of a hospital.

Whoa! Stop the presses! In the State of California the STRUCTURAL ENGINEER has no limitations on what they may design, but the architect cannot design portions of a hospital. Interesting, but this didn’t really fit what I was looking for in an explanation. I found the following on Google Answers and I believe it does an excellent job of qualifying the term, and title, architect across all vocations.

“Historically, the architect has been the coordinator of all other disciplines involved in the building process. According to training and licensing exams, architects must be able to integrate all building disciplines to protect the overall health, safety, and welfare of a project. We are responsible for not only this integration and the accessibility of structures and their surroundings for human use and habitation, but also for the end result in terms of use, quality, composition, and appearance; engineers are responsible for the application of mathematical and physical sciences, within an area of expertise, and the related health, safety, and welfare. While architects are tested in engineering systems [structures, electrical, mechanical, and site design], building construction materials and methods, codes, contracts, programming, spatial relations, history, and theory, engineers are tested only for specific systems and disciplines. Engineers have a narrow focus; architects bridge the gap between the systems [what engineers design] and what the community needs.”

source: aiapa.org,

So, based on his explanation the engineer is responsible for the design of an entity, typically to the exclusion of the environment in which the entity will exist. The architect is responsible for ensuring that the entity also serves and does not negatively impact the environment in which the entity will exist. Hence, the architect needs to fully understand and be a master engineer, but also have experienced how past engineering projects have impacted an environment once it was introduced.

I guess, a good question on an interview for an architect might be, “in a past system in which you led the systems engineering design, how have you had to change the design once the system was put into production?” I would follow up to this question with, “what factors led you to know what changes were required?” I believe my final question might be, “on your next system design what factors you anticipated to limit the requirement to make changes once placed into production?”

Thus, architects need to think strategically about the use of end product, whereas engineers tend to focus solely on the end product. This begs the question, “do engineers need to fully understand the big picture, or just focus on building the building?” This is an interesting area onto itself. For example, what if the architect didn’t think of everything? What if an engineer is familiar with problems with using a particular material on a job that the architect recommends?

To fall back on a structural building analogy, it seems that it could be very disruptive to have an engineer focused on whether the placement of the front door is placed optimally for access from the parking lot. At some point, the engineer has to trust the architecture and the architect has to trust the engineer. However, this is the focus on a whole other blog entry. To complete the thought, I am on the side of separation of concerns, but an engineer who is bright enough to consider the optimal placement situation should be a target for apprenticeship to become an architect.