One of the recurring themes in the ongoing development of Information Technology (IT) as a discipline is the concept...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
of "business-IT alignment". It's surprising we even have a need to talk about business-IT alignment given that we don't talk about business-finance alignment or business-sales alignment or business-anything else alignment. Why is it that IT needs a special alignment with business? Is the concept of business-IT alignment itself a smoke screen for selling products, services, consulting, and analysis that present little value to the organization?
While it might be convenient to jump on the beat-your-vendor bandwagon, the sad truth is that IT does indeed need alignment with the business. No other function of the business (sales, marketing, finance, HR, supply chain, and manufacturing) can so easily get out of whack with the needs of the business and fall down the rabbit hole of spending without clear return than IT. When technologists are in charge of IT, the business is in trouble. However, the business can't speak the language of technology, and thus, we have an alignment problem. More precisely, we have a synchronicity problem. The business wants their technology-driven needs met with as little delay and as much precision as possible. Technologists want new capabilities to provide benefit and increase competitiveness as quickly and with little latency as possible. The more we align, the more we act in a synchronous fashion. But the word "alignment" has much more of a management-consulting tone to it, so that's the word we use.
In our "Problem with IT Project Management" and "The Third Conversation" ZapFlashes we talked about rethinking the whole business-IT alignment concept and how it basically hinges on changes to culture, organization, and methodology more so than any technology implementation. As such, there exist many different approaches to solving the challenge of business-IT alignment. Many of these approaches hinge on finding an optimal way to accurately represent the needs of the business and quickly implement those needs such that results can easily be quantified and the cycle begun again. From this perspective, the role of service-oriented architecture (SOA) has a unique role to play: reducing the cycle between business request, implementation, and iteration, and facilitating solution of business problems with technology-driven capabilities. To the extent that business services are abstractions of continuously changing business needs, the goal of SOA is to facilitate alignment by eliminating the activities of integration and development that usually get in the way.
The service contract: Where the IT rubber meets the business road
We've frequently discussed the central role that service contracts play in realizing the vision of SOA. Within those ZapFlashes, you will clearly see that the service contract is the core artifact that bridges the gap between business requirements on the one hand and IT capabilities on the other. While we've focused on the service contract from an architectural and technological perspective, one of the things we haven't focused on is how the use of service contracts can change organizational behavior to facilitate business-IT alignment.
Most organizations document business requirements using a combination of human-oriented documents, requirements generation tools that help to organize such content for human consumption, and the smattering of models, documentation, and guidelines that together act as a basis for distilling the business needs into technology capabilities. However, these narrative-style approaches to business requirements generation and documentation rarely have the sort of precision that the business needs. Indeed, there is too much room for interpretation from IT within the documented requirements, and too much ambiguity in how technology-specific requirements should be addressed within the context of business needs. For example, a business unit might specify their functional needs, but leave the non-functional requirements (such as security, reliability, management, service-level, infrastructure choice, flexibility, and reuse considerations) completely in the air. When the IT organization is left to their own devices to "fill in the gaps", that's when trouble starts.
Bringing back SOA into the picture, we quickly realize we have a better tool at our disposal for documenting business requirements than a collection of human-oriented narrative documents. The service contract needs to be just as specific with regards to business-level functional and non-functional requirements as it is with regards to technical capabilities. In a contract-first style of service design, if something is not specified in the contract it is not implemented. If IT needs an ambiguity resolved, it must be placed into a contract, which the organization in turn must go through a negotiation process with the business.
This loop between the business and the service contract on the one hand and the IT implementation and the contract on the other represents the SOA Metamodel that we so frequently discuss in our training. Not only does it represent an architectural approach, but we believe it must also represent an organizational approach to managing business requirements. In a flexible and continuously adaptable IT-enabled business organization, the contract represents the business requirements in their purest form. The business relates to IT in terms of contracts, and the IT relates to the business in terms of contracts. The enterprise architecture (EA) organization manages contracts and makes sure that contracts are consistent, not duplicated, iteratively developed, and easily implemented. This focus on the contract is a shift not only in the way IT works with technology, but also in the way that the business works with IT. If we can get business and IT (literally) on the same page by using contracts as a lingua franca, we have a shot at making the business and IT operate as one.
Before we get too enamored with the contract-first approach, it's important to realize that the business and IT can still get hung up in the service contract generation process. When the business or their Business Analyst (BA) representatives are involved with contracts, they are thinking about the contract as an aspect of the abstracted service, not the individual service interfaces. On the other hand, when IT is involved in service contract design, they are frequently thinking about the service interface and not the abstracted service. The service contract itself must be a combination of the two, as we've defined in the other ZapFlash articles above. To avoid misalignment at this critical aspect of service design, it's important that the service contract define the abstracted service as well as the requirements for the service interface. In many ways, the service interface is subservient to the abstracted business service. The service interface simply represents how consumers access the service, which is only one aspect of the service contract, as we've defined it. Indeed, there can be a one-to-many or even many-to-many relationship between the abstracted service and the service interface. It is the role of the service contract to establish this relationship.
There's no reason to reinterpret business requirements in the transition from business abstraction to service interface. And while the business service contract would more likely have written requirements whereas the service interface contract might simply be WSDL, the service contract serves as the single unifying document that aligns these two service concepts. To avoid the possibility of ambiguity, service interface considerations would have to be placed into the same service contract that defines the business abstraction. The service contract that business talks about and the one that IT talks about must be the same thing -- we don't have business abstraction contracts and service interface contracts. The business abstraction is represented in the contract, and the requirements for the service interface are likewise represented in the contract.
The ZapThink take
In many ways, the service contract represents more than simply a reflection of a business requirement or a technology implementation. Indeed, the business requirements and technology implementation are subservient to the service contract. The service contract itself represents the commitment that the business makes with regards to its needs, and the obligations that IT will undertake to meet those needs. In this regard, the service contract is itself an essential negotiation tool in the business-IT dialogue. If business and IT can come to terms and define those terms the business needs can be met with technology capabilities. If they can not come to terms, then the business risks its needs not being met, and IT risks unreliability, wasted time, and needless effort.