Offshoring is often done on fixed price terms. The financial size of the project and the way in which the contract and subsequent remuneration is managed relies heavily on specifications, governance of the delivery and change management. To date most offshoring companies have similar, although with subtle differences, models for doing this.
The advent of UML as a language for modeling and specifications has certainly helped in understanding what should be delivered. The use of programme management and enterprise architecture functions to govern delivery with clients is a common feature. Many offshoring companies and indeed those that were local Systems Integrators have to a large extent pioneered the roles that we play; from the programme management roles to the enterprise architect roles. Governance and supporting frameworks have been developed to help the process and have been used to great effect. TOGAF certified architects, MSP certified programme managers are in demand. Of course this does not mean TOGAF and MSP are the only games in town, I only mention them because they are well known.
The fundamental cost in offshoring the Software Development Life Cycle (SDLC) is one of people. And because people are involved the removal of ambiguity in specifications where possible is a critical success factor it both protecting the margins of offshoring companies as well as protecting the delivery of solutions to customers.
Not much has changes in terms of the specifications and the methods to create specifications nor in the way in which specification are used to guide the SDLC. Typically success is characterised by a model in which an Enterprise Architect may work alongside Business Analysts onshore to frame a solution and the Programme Manager liaises with the customer and Enterprise Architect to ensure a suitable roadmap for phased delivery of the solution. The same two roles work together on the contract details which reflect the roadmap. The programme (that is the collection of projects needed to deliver the solution) kicks off and the Enterprise Architect and Programme Manager (often with similar roles from the client) ensure the programme is well governed meeting all the targets and adhering to the standards of communication and delivery needed as well as managing changes.
Within the process that is enacted the specification of the solution becomes a key part for both governance and change management. The specification is the document (or documents) that detail what needs to be built in order to deliver the solution. Of course the entire process is larger than just this piece but for the most part the rest of the process deals with change management and seeks to ensure alignment of the solution to the customers needs throughout the life of the programme - hence change management because what we think is correct never is what is needed over the life of a programme; things change.
The specifications delivered to an offshore engine need to make clear what functions need to be written, what inputs they might have and what outputs they might deliver. The specification needs to make clear the order that functions can be used. I have not mentioned data explicitly because it has no meaning without the functions. A piece of data is just that until we decide to do something with it. What we do with it is essentially a function.
The challenge to creating and delivering good specifications is to ensure that they are internally consistent, that they are externally complementary - by which we mean that two pieces of software will work together or interoperate, that they are aligned to the business goals of the customer.
The way in which we meet the first challenge - internally consistent - is largely through governance and within it review. They way we meet the second challenge is the same. The way we meet the third challenge is through transparency with the customer of the SDLC and the solutioning process and of course through continued governance.
Of course when things change we need to assess the impact of that change to projects already in flight. Again this is done through review under governance.
The pattern here is that the key challenges are met with people based processes. And the problem with that is that it is ambiguous. The specification are often ambiguous internally and even more so externally. Not because people are not trying by because the level of abstraction for specifications is not amenable to adequately describe what is needed.
If we use UML State Machines and WSDL contracts as an example. We might have 100 services to create. They all have WSDL contracts. Some of the services will be stateless (typically data look ups, technical services and so on), some will be stateful (this doesn't mean they hold state within the interface but it may well mean that they have knowledge of one or more business transactions and so state relative to the business transaction becomes very important). If 20 of these services need to collaborate then the UML State Machines need to reflect that collaboration. The way we ensure it works is to check each State Machine against what we think are the related State Machines. As an example look at the two below, they should be complementary but are they?
Life got a little better when BPMN came along. It's level of abstraction is higher. But the problem with this is that it very quickly becomes unmangeable and unintelligable because the complexity is delivered as links across services (the roles or actors). Imagine a BPMN diagram for a seemingly straight forward problem. I show one below and you see immediately that the complexity makes it unreadable (and yes I know it is small but the point is that the picture is clearly complex).
So how do we do it better? How can we deliver better specifications and so improve the global delivery model and leverage offshoring at an industrial scale without needed so many heavy people based processes? In short how can we automate some of this and use computational power to make our lives easier?
The answer is to use testable architecture. In my next blog I shall show how it works and how it can be applied and the benefits that ensue. I shall leave you now with a simple business view of testable architecture for a simple example that was generated from a language that is unambiguous and really does specify at the right level of abstraction:
