SOA Readyness

I'm wondering if my company is ready for SOA. Right now the various business units in the company support many pieces of custom built technology which provide essentially the same functionality. Consolidating this functionality into a common, shared set of services is what SOA is all about right? Not only will the footprint of what we need to support be smaller, but we'll be able to meet future business needs faster (getting a jump start by reusing these prebuilt, prepackaged, pretested functionality). Isn't SOA a no brainer in this instance? I'm not so sure.

Building successful SOA components (even ones designed for internal use) need a product development approach. Code before SOA is essentially "set it and forget it". Failures in a particular component have a relatively small impact. In a SOA solution, things like scalability, stability, support, and release management are much more important. The significance of these traits increase proportionately with the number of clients to a particular component. All of a sudden you go from a situation where a software bug might affect a single business unit, to the point where the same bug could affect the entire enterprise.

I've already discussed the company's poor release management procedure. Its system is not conducive to concurrent development. This is needed to support released SOA components while the next version is in development. Strike one.

Currently, there are no test suites or sets of regression tests for this company's systems. Sadly, there is little desire to build any. Regression testing is important because as we enhance the services, we need to ensure we're not breaking any existing functionality. Creating a custom set of tests for each change to a service wastes time and is itself error prone. Without a good set of tests, the stability and support-ability of the service is in serious question. Strike two.

Scalability is always a concern, but since this code will now be responsible for handling more transactions (since it likely supports more than 1 client) any problems with scale will appear sooner and affect more business units. Strikes one and two affect our ability to effectively address these performance problems. Strike three.

It seems like SOA in this environment is a disaster waiting to happen. Until the release and testing issues are addressed, I do not see how it can succeed.

Comments

Post a Comment

Popular posts from this blog

I Believe...

A recent reorg at my company left me with a new manager - and a different approach to software development than my team had been previously following.  Our new approach is one that I don’t necessarily agree with, but it led me to think about - and reevaluate -  those tenets of software development that I think are important and that I believe lead to increased quality and productivity. This post will consist of fairly high level discussions about how to organize code, teams, and projects - but contain very little actual code. Many of these ideas will not be my own.  They are mostly ideas I’ve learned from others and their willingness to share their experiences with me.  They are, however, ideas that I’ve practiced and hardened as I’ve worked to build my own ideal environment for delivering value through software . Many of these ideas I now take for granted as commonplace (even though they aren’t).  I felt a need to document them anyway - so people can understand what to expect (a
Read more

Performance Tuning JCAPS - Part 2

It's been close to 2 months since my first Performance Tuning JCAPS post. Since then, we've noticed our servers running out of TCP connections under heavy load. Researching this problem, we learned that the JCAPS' JMS server makes heavy use of TCP in implementing Request/Reply queues . We approached Sun for guidance and they assured us that they've had success implementing high throughput applications using the JMS request reply solution... but how? It appears a multi-step solution is needed. First, running out of TCP connections in a scenario like ours is a JCAPS bug addressed in an ESR (110348) and rolled into JCAPS 5.1.3 Update Release 3 . We installed this update and noticed a marked improvement. Running my simple 75 user simulated test, transactions took 2521 ms to round trip (compared to the previous time of 20128ms). While this is great improvement, an average of 2.5 seconds is still really slow for this simple transaction. We reported our findings to Su
Read more

FRail :include

I really like developing with Rails, but I've been frustrated the last few days by some things Rails should do quite easily, yet doesn't. I've already written here and here about some of my struggles with Rails :include clause. Here's one more... Let's say you have a has-and-belongs-to-many relationship. If you :include this relationship in a find query, Rails will automatically create the join clause including the lookup table! That's cool. Unfortunately, it looks as if only the :include clause provides this piece of functionality. Why isn't the same functionality provided via the :join clause or through a general purpose module? This doesn't make any sense to me! I'm working on a database application where I don't need to display a lot of data, but the data displayed is heavily filtered by it's connections to other information in the database. I need to join a lot of tables to perform the filtering operation and using :include
Read more