The Tech Evangelist Leading IT Innovation One Blog Entry At A Time

21Jul/0910

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?

Comments (10) Trackbacks (3)
  1. Good points. The lack of a focus on contracts, in particular a runtime mediatable contract, is a problem. The problem is made even worse by the vendor driven approach of building another “abstraction” layer on top of well-established protocols, such as WSDL and WS-Policy.

  2. Well articulated points. Good. Most of the time the choice of tools and technologies are based on several unimportant factors. I like the point of a single solution architect driving the entire group being the owner for choice of tools and technologies. This would definitely help to rationalize.

  3. Noble thoughts – but it never works in practice. It is like trying to have a centrally planned ecomany rather than a market driven one.

    • Udayan, these are very pragmatic management decisions. Put the right people in the right seats on the bus and you will be successful. Technology is such a small component of success. Selecting the wrong people, based on the wrong criteria is a primary cause for failure. Over the years, I’ve been asked by senior SD managers to review the work of their teams because they don’t believe the reasons for their team’s failure to deliver as expected. The fact that these SD managers didn’t have an in-house resource leading design and providing this insight was a major flaw in their business strategy.

  4. Udayan, you make some very good points. Yet, they seem to all be focused on technology issues and senior technologists running the show.

    I believe that Enterprise Architecture is primarily about the business. SCA can provide an excellent standard for defining enterprise integration points, since it requires the definition of both services and all service references.

    Imagine having all of an organization’s integration points so well defined that the flow of information or the steps of processes could be tracked and reported. Corporate management could begin having a better understanding of IT complexity resulting in better decisions.

    I believe helping management make better decisions is part of our CAEAP oath.

    • Tom, I agree with your points about needing enterprise integration points defined, but don’t see that SCA is the best tool to gain that advantage. I’m not supporting SCA in this piece, so I don’t exactly understand how your comment fits in with this thread.

  5. Integration is not equal to architecture.
    Architecture always exists – it might be bad, not understood, inflexible, but it always exists.
    Integration (EAI, EII, SOA whatever flavour you like) may or may not exist, and it’squality and TCO may vary.

    SOA (done right) is certainly one of the best (easiest, most cost effective, most adaptable, etc) integration methods I have seen yet, and also one that is most amenable to re-archtecting initiatives.

    I’m not sure exactly what this SCA beast is yet – it must be a fairly new vendor-led buzzword designed to sell otherwise non-moving lines of products and services:)

    • Nic,

      I’m not 100% sure what you meant by including SOA in the integration list. SOA is not about integration, it’s about the alignment of business function into a services model that may be provided using technology, but is not required.

      JP

  6. Good Points!

    Actually I am trying to provide approaches with some IBM tools to achieve productivity. And we have to overlook the practices recommended by the vendor with the ones deviced by us. Just doing this our whole of SOA governance has got streamlined.

    I truely agree with your views and have personally experienced in around 4-5 projects till now.

  7. Some Good Points JP – Thanks for sharing. Totally agree with them.

    I wish every organization had used this more strategical approach as mentioned by yourself but I see many organizations still getting influenced by these vendors who use these buzz words to sell their expensive products (and even services if they are able to) to the ignorant and confused IT/Business senior executives.

    So a practical question : What should a SOA Architect/Designer do if he is working on a SOA project where SOA is not a strategical solution but just tactical/project level “IT” Solution “sold” by vendors and SCA is vendors promoted SODA/SOBA implementation/development methodology? You probably would agree that there are lots of such places and the role of SOA Architect is just limited to a tactical Solution Architect and Organization is not ready and yet prepared to listen to and think in a Strategical SOA way. Should s/he take a bold (and revolutionary to some extent) decision to just design simple SOA services using the vendors tools? OR s/he should make the best use of SCA to build the services as “SOAed” as possible keeping in my mind that the complexity introduced by SCA is not just an architectural complexity instead could even be a runtime complexity becs introducing unnecessary layers in a software design means more iterations or pass thru points at runtime which may well have some performance impact as well.

    Thanks.


Leave a comment


*