This week we are at Gartner's AADI (Application Architecture Development & Integration) conference, and talking to a lot of managing architects and developers from all kinds of industries. And what we are seeing is fundamentally a recovery from the hangover of initial attempts at SOA strategies.
The story is fundamentally the same: "We were trying to modernize our legacy apps, and then we needed to interact with some third party applications, and an acquisition was involved, and we outsourced some development and/or testing tasks... so we tried building some services on top of that..."
Initially, it all works out pretty well. You take some requirements, put web services in front of some legacy apps, and tie those to a web interface and voila - a new SOA app. The initial results look good, the consumer can accomplish their business tasks. Then, get more teams to start consuming the service for different business processes, and bringing more interdependent services into the fold. It doesn't take long for some real problems to arise.
Moving to SOA does create more flexibility and agility, but it also creates a lot of fragility -- in that all of the services we use have underlying business systems that contain the real workflow, and therefore teams don't have enough access to the systems they need to properly test and develop their components as part of the overall workflow. This can cause huge quality issues later in the lifecycle, as well as a much slower time-to-market and higher costs than expected.
Obviously, hearing the good word from the analysts will help. But so will a little old advice about the "hair of the dog" cure. If going services-oriented has got you down, the answer is -- more services? Well, exactly. The caveat is, making that foray into SOA is going to be flawed, if it doesn't dispose of the assumption that things will work together as expected.
Re-committing to services can actually turn this situation around. This can only cure the SOA hangover if:
1. We are setting clear Policy expectations for both the provider of the service to meet expectations, and the consumer of that service to define exactly what their intended uses of that service are as verifiable tests.
2. We are providing a system of record for enforcing these service policies, and how they are used to meet a business need. For instance, we recently worked with SOA Software around just this piece of the puzzle. Their governance framework stores tests as a way to manage the enforcement arm of the design/build/change process in their platform. There are many other leading governance and development process tools that can store tests as verifiable enforcement points in this way.
3. We Virtualize the dependencies of services. When we start splitting up teams and the services we deliver, we expect that we will get more agility. However, inevitably these teams run into the barrier of dependency on services that are either not yet created, or aren't available (such as constrained live mainframes and services that aren't yet created). By basically capturing and simulating Services and their underlying layers, these teams can move their development into a more parallel development and testing process at a component level, much earlier in the lifecycle. Time to market and delivered quality, as well as lower environmental costs arise out of this level of virtualization.
Just an initial musing from this show - the quality of discussion has been really good here so far. Look for some more thoughts from our sessions here.
Comments