Contract-First Development of Services

Contract-First development of services will help companies move towards a service oriented architecture (SOA). When you can abstract code into services, it makes it easier to use those services as pieces and plug them into where ever they might be needed. By first building the service's contract, it provides the structure to define and make those pieces work together.

However, what IS a service? Some might say "it's a web service" or "It is creating modular, reusable code." It is true that the web service standards are important and re-usability is an important attribute. However, by taking the view that a service in an SOA is more similar to a lawn service than a web service helps debunk the notion that services are simply code that can be easily called from anywhere (Modularity). Instead, it allows us to consider that a service as a stand alone piece of functionality.

When you hire a traditional service such as a lawn service, the first thing that occurs is an agreement as to what will be done. The elements of this agreement include the name of what will be done, what the customer has to provide and what the end result will be. The agreement will also include performance and response time criteria. In the end, as a consumer, I don't generally care if my lawn care provider cuts my grass with a 20k dollar mower or a push power or a pair of scissors. The implementation is up to the provider, SO LONG as it is implemented meeting the agreement. We call this agreement a contract.

Services found in an SOA also need this type of agreement. A service contract includes both functional and non-functional requirements. The functional requirements include what the service does, the service interface and the means of invocation. the non-functional requirements include service level agreement, security and quality of service, transactional constraints, process and semantic definitions.

You might ask, "Why do I need this contract? What does it provide for me? Can't I just use the interface?" The reason you need it is to give the service it's own scope of responsibility. A basic tenet of SOA is that a service is an autonomous unit of functionality. Also, it provides a definitive scope of what that service need to provide. A contract increases visibility and provides a neat package of functionality that can be used as a component in our application infrastructure.

Another advantage in knowing the functional requirements is that before the code is even created, test cases can be developed to determine if the services performs the required functionality within the constraints of the contract. Some call this test-driven development.

Stability of the system is critical when you create a SOA. This stability is improved by the versioning of ontracts. Once a contract is established, it can not be changed and it must be supported as long as consumers exist for it. However, new versions can be cloned and modified. By having both versions of the contract supported, new functionality can be built and made available to early adopters while the old contract is still supporting other applications. This allows a company to be agile in reacting to business changes while not breaking existing applications.

Lastly, the contract should state ownership and responsibility matrix. This is in the form of who is involved as well as who is responsible for the evolution of the service. The RACI is a great starting place to show these stakeholders. RACI stands for Responsible, Accountable, Consulted and Informed. I have always had an issue between Responsible and Accountable. They seem very similar. So lets do the easy ones first.

Consulted represents the set of people who have input in to the contract. They are typically the main consumers or business subject matter experts. The important part is that this is a two way communication. Informed are the set of people who need to know about changes or the development of the contract, but do not have a voice in its creation. This is a one-way communcation.

Now for the difference between Responsible and Accountable. Responsible to me is the person who owns the problem or, hopefully, owns the vision. Accountable seems to be the person who has to approve it. One variation that I like more for the 'A' is assists. Who assists the Reponsible (Visionary/Owner) in making the vision a reality.

Assemble-to-order: How using it can improve agility and operational alignment

In manufacturing, there are several categories of production. A manufacture can be a "build-to-order", "engineer-to-order" or "assemble-to-order" shop. Engineer and build-to-order means they make their products from scratch or raw materials. This is the most flexible, but requires a longer lead time to make the final product and therefore is less agile. Assemble-to-order means that themanufacture take parts called assemblies, put them together in different interesting ways to create the mered of potential final products and thereby increasing agility. An example of this would be Dell Computer. When they take your order, they have lists of options for each area or functionality. These areas would include disk drive, motherboard, ram, operating system, monitor, etc. This ability allows Dell's customer to mix and match their system based on their needs.

Service Oriented Architecture gives IT shops the same advantage to their customers. By design, SOA helps engender the "assemble-to-order" mentality that is needed in order to become agile. In these terms, an SOA service is functionality. It abstracts or hides the complexity of "how to do something." So, this service is the equivalent to the assembly part in the manufacturing process.

IT shops have to decide on how to get these assemblies or functionality and what are the assemblies they need. The ability to make these decisions separates the successful implementers of SOA from the frustrated. Answering the how question better allows more agility. Answering the what question better allows more organizational alignment. Let's focus in on both.

The how decision affects agility because of resource allocation issues. With unlimited budget, talent and time, we would build everything from scratch because it specifically addresses our issues. Since this isn't the condition we live in, we have to decide what we build based on things that will make a difference for us in the marketplace and things that we have thecompetency to build. We need to allow others (3rd Parties) to build things that don't make difference for us or that we don't have the competency to build. A rule of thumb is from Anne Lapkin of Gartner , "Build for competitive advantage; buy or reuse for competitive parity." The beauty of this principle is that not only does it limit what you build, but also indicates who you should hire.

As we increase our understanding of the functionality needed to enable business processes, the more IT can serve the organization as a whole. Business are in essence a collection of processes, ideas and effort. Processes are broken into steps. Each of these steps is a function. An action to be taken. To help define the set of functional steps, an enterprise should develop a vocabulary. (There will be further blogs about vocabulary)

In the beginning, it may seem to have a lot of overlap and confusion as to what is a service. How granular to make the service. The rule is to make it large enough so that a typical person who deals with that process can understand what is happening but no more than that. This is what I am referring to as the Middle Ground between the Business and Information Technology. This is the chasm where chaos rules in today's business and IT integration. Semantics, language, comprehension of processes from differentvantage points all lead to this ineffective integration.

It is this chasm which causes a lot of the confusion. But it is also the place of the richest gains in productivity can be gained. I am not saying that to tackle all of the middle ground issue at once, but once familiar with the tools and how to use them is achieved, find an important but not mission critical process that lives in this middle ground to work on first. Use enterprise architecture vocabulary to name and describe the steps for the process. Then build, buy or reuse the services named according to the Build-Buy principle.

An important note to remember is that there may be more granular services that your higher level services use. The services in the middle ground are the ones that need to be understandable to the typical business person using that process.