Here’s the first draft of an essay I’ve been working on. Call it version 1.0. I’d be happy to hear your feedback before I add the finishing touches.
SOA means a lot of different things, depending on who you ask. Let’s talk for a moment about SOA’s role in the application development arena, which most would now term the application lifecycle.
Before SOA was introduced as a concept, there were plenty of problems in application development. I’m going to lump these into three areas: demand, delivery, and management. SOA doesn’t fix any of them, in fact it can make them far worse.
DEMAND
Starting with demand — the earliest stage in which a business identifies that it has a requirement that it needs IT’s help to fulfil — there was a communication gap between the business stakeholders and the IT department’s developers and development managers or developers-cum-analysts.
Business people are notoriously bad at fully and accurately describing just what it is they are trying to do in terms that the IT experts can fathom.
IT experts are equally bad at translating business requirements into specifications for what they are actually going to build, and even worse at translating those specifications back into something that the business can understand sufficiently to know whether o give them the go-ahead to start building the prototypes.
Content from our partners
SOA doesn’t solve either of these problems. SOA has not provided a miracle shared vocabulary that both the business and IT experts can agree covers what each needs to understand about the business. So at the demand stage of any SOA-driven development cycle, there are the same problems of miscommunication of requirements and specifications that preceded SOA.
Business people may be more comfortable talking about the services that they want built for them than talking about the heterogeneous mix of databases, application servers and interfaces that go into building the system.
But with an SOA approach, the developers are thinking about services specifications built with standards like Java, .Net, BPEL, SOAP and XML that are still meaningless to the business users.
With SOA developers may not need to worry about such fine-grained components that were the norm previously, in the era of component-based development (I’m thinking the likes of CORBA and DCOM). But the granularity of the SOA-era components; EJBs, BPEL transactions, XSLT style guides, still have business people baffled.
SOA doesn’t necessarily close the communication gap in the delivery stage of the application lifecycle.
DELIVERY
This is the stage at which developers have actually built something, and they are ready to put it into production. Historically, the problems here stem from the problems in the earlier demand stage of the lifecycle.
The developers have either built the wrong thing or only solved half of the problem. Traditionally, the business sends the developers back to the drawing board to try again — there are usually multiple attempts at getting it right — so is this stage easier to do quickly when the system has been underpinned by web services and SOA? It’s unlikely.
When developers built their systems using fine-grained components (or even before component-based development) developers could go back to their designs and modify fine-grained components or just chunks of code without worrying too much about how those changes affected other ongoing development projects reliant on more coarse-grained services.
Now with SOA, the systems may be a mashup of web services, so if the application is to change they may need to consider how that affects other, parallel services developments in the organisation.
In a worst-case scenario, they may need to swap out existing services they found in the services repository with other services that do now meet the new business requirement as they understand it.
Worse still, the new understanding of the requirements may not have any alternative underlying services in the repository, forcing developers to build one or more new services from scratch — while any new services builds should adhere to the IT department’s policy on encapsulation, standards, potential for reuse and so on.
What the IT department promised to the enterprise with delivery of a matter of weeks or months because they believed they could deliver it by mashing up existing services, suddenly needs a lot more time as they realise they must build new services too.
Again, the business cares less about whether what is delivered to them was developed more efficiently because it is a mashup — they just want it delivered in a way that meets all their expectations, and they still want it delivered according to the original target go-live date.
The delivery of applications and systems to the satisfaction of business stakeholders is not solved by SOA; in fact an SOA approach could even add to delays in getting the functionality delivered.
MANAGEMENT & SCOPE CREEP
Let’s look at the third element I have earmarked in the application lifecycle: management.
Before SOA, managing application development projects was no easy task, it’s true. Depending on the granularity of the application development approach prior to the adoption of SOA, it was not always easy to break development projects into piecemeal parts in order to get them built by distributed development teams inside and outside the organisation.
SOA itself does little to help here. The chunks may be larger, but project managers must now also pay lip service to the corporate standards for services development: again, things like choice of tools vendor, standards, reusability and documentation.
They now have a repository and registry of services to think about, and they may need to be mindful about SOA governance — who ‘owns’ certain services, services version control, security implications of shared services and what impact changes to underlying services have on each of their live applications that rely on them.
SOA doesn’t solve the challenges of managing application development projects. Indeed it adds another dimension where the manager must be mindful of the change impact of their own and other services built inside or outside the organisation on the applications and systems they deliver to the business.
Once the application is delivered, much of the systems management and service level management technologies that helped the IT department keep track of bottlenecks, errors or outright outages are more advanced for more traditional applications infrastructures than they are for SOA deployments.
Visibility into databases, application servers and front ends is a solved problem thanks to the systems management vendors. But management visibility into systems and applications comprised of shared services is a more nascent field. The systems management and business service management vendors are catching up, but setting up management reports that the business requires to handle shared services inside and outside the business sill takes considerable work.
Don’t get me wrong. SOA done right can have huge benefits: the likes of re-use, the ability to more easily produce composite applications or ‘mashups’, even some improvement in the shared vocabulary between business and IT.
My point is that if you don’t get the fundamental challenges of application development under control first, SOA can be even more challenging than more traditional component-based development approaches.
The answer? IT governance – call it SOA governance if you wish – and business process management (BPM). IT governance is a must-have for SOA to work. Meanwhile BPM, to my mind at least, adds an essential veneer atop SOA that helps to abstract away some of the difficulties I have outlined in the requirements/demand stage, and even more of them when it comes to delivery and ongoing management.
In chapter 2 of this essay I’ll look in more detail at why SOA governance is so vital for the success of SOA-based strategies. Look out, too, for CBR’s forthcoming special report on BPM in which I’ll delve deeper into my views on why BPM is essential for SOA (despite the fact I don’t believe SOA is a pre-requisite for BPM).
As always, your feedback is most welcome.
