Market conditions are in a constant state of flux. The economy is, well, the economy. The regulatory environment shifts based on the latest business scandal and which political party holds sway. Plus, there is always a new management strategy to solve world hunger or something. As users struggle to keep up with this deluge, they frequently turn to their friends in IT for help. In this way, IT feels the impact of these external pressures indirectly in the form of requirements.

IT's management applies pressure of their own with demands to do more with less, be more efficient, outsource more or cut staff more.

Working in IT is like living in a pressure cooker.

How can you address these sometimes opposing pressures and find some relief?

Just What Is It, IT?
A useful first step is to consider just what is IT anyway. One common framework for understanding IT is people, process and technology.

People, of course, means your staff, whether they are full time, local consultants, or offshore partners.

Process refers to governance, how decisions are made regarding application design, purchases, resources usage, requirements gathering, and so on.

Technology consists of applications and the infrastructure on which they run. Applications may be built, bought or leased. That is, applications may be "legacy," Commercial Off-The-Shelf (COTS), or provided on a Software-as-a-Service (SaaS) basis.

An IT Carol
It is also useful to consider in greater detail the nature of business requirements as they are the impetus for IT's very existence. Little could he know it at the time, but Charles Dickens provided a perfect metaphor for this exercise.

"You will be haunted," resumed the Ghost, "by Three Spirits."

Much as Ebenezer Scrooge is visited by three Christmas spirits to bring purpose to his life, IT is haunted by three requirements spirits to bring purpose to its existence: the ghosts of Business Requirements Past, Business Requirements Present, and Business Requirements Future.

Business Requirements Past are requirements that have already been met by an IT solution. Business Requirements Past manifest themselves in current IT activities in the form of support, for example, troubleshooting, errors remediation, and minor enhancements.

Business Requirements Present are current needs. They must be interpreted before they can be implemented. Tasks associated with Business Requirements Present are more challenging to fulfill than those associated with Business Requirements Past because Business Requirements Present lack IT specificity. That is, they typically are represented in business terms that don't map directly to IT concepts.

"Ghost of the Future!" Scrooge exclaimed, "I fear you more than any spectre I have seen... Will you not speak to me?"

Business Requirements Future are requirements yet to be. IT has the same fear of the Ghost of the Future as Scrooge does, for like that ghost, the spirit of Business Requirements Future does not speak. Business Requirements Future are latent, unarticulated even in business terms, for which IT nevertheless is expected to be prepared.

To meet Business Requirements Future, IT must provide sufficient application and infrastructure flexibility such that when these requirements come to pass, they can be implemented without undue burden. This is the essence of the elusive IT "agility." Figuring out where and how to engineer such capabilities is far more challenging and risky than the efforts involved in supporting Business Requirements Present, which are at least known, albeit only from a business standpoint.

This view of IT and the pressures applied to it is depicted in Figure 1. We will refer back to this model throughout the subsequent discussion.

"Men's courses will foreshadow certain ends, to which, if persevered in, they must lead," said Scrooge." But if the courses be departed from, the ends will change."

The same is true for continued existence in the IT pressure cooker. What is needed is a new IT approach, and consequently changes for IT in terms of people, processes, and technologies.

Okay, Now What?
The remainder of this article will discuss how the principles of a service-oriented architecture (SOA) can relieve these pressures and outline how SOA can be approached in the context of people, process and technology.

Pay No Attention to the Man Behind the Curtain
Ironically, while we will present SOA as an approach of paramount importance to IT, SOA per se is not relevant to business users. They don't care about SOA. They shouldn't care and, if they do care, you have a problem. SOA is first and foremost a design consideration. The last thing you want is for users to design applications. If users were any good at this, there wouldn't be a need for IT in the first place.

If SOA is successful, its value to users will be evident in what it enables in terms of faster delivery, higher quality, and lower costs. Eventually, a successful SOA will have more of an impact on requirements as IT gains experience and as libraries of reusable services accumulate, but that takes time.

Something Old, Something New
There are many defining aspects of SOA. Previous issues of this publication provide numerous general descriptions of SOA. For the purposes of this discussion we will focus on just two: services and loose coupling.

While SOA borrows much from established IT approaches, the notion of delivering software components as "services" is more novel. This approach more naturally parallels business processes than previous approaches based on objects or subroutines. This inherent affinity between software services and business processes is important because business processes are a common vehicle for describing requirements. IT designs based on software services are naturally better aligned with user requirements than IT designs based on previous paradigms.

The transition between requirements and design represents a sea change in the IT solution delivery process. Up to this point, descriptions are problem-focused and decisions are business-driven. From this point on, descriptions are solution-focused and decisions are technology-driven.

Failures at this juncture can lead to much frustration for both users and IT, even if the delivered solution appears to meet stated requirements. This is because applications are built differently than they are perceived. Unintended ripple effects arise when either the business or technology model requires change in ways that violate assumptions underpinning the other. Naturally, such change is inevitable.

Turn and Face the Strain
Sometimes change is user-driven. When seemingly straightforward proposed changes to the business model have disproportionate implications for the technology model, IT is viewed as inflexible.

Sometimes the change is IT-driven. When seemingly straightforward proposed changes to the technology model have disproportionate implications for the business model, technology breakthroughs that offer cost savings, risk mitigation, or productivity enhancements are bypassed. As a result, IT misses opportunities to save money, personnel, computing or other resources and IT is viewed as inefficient

No matter how technically astute business users are or how business-savvy IT personnel are, there will always be a leap required between the desired user experience and the technology provided to deliver it. A service perspective doesn't eliminate that gap, but it does help narrow it.

Beautiful Looser
The second key SOA principal relevant to this discussion is the concept of loose coupling. Loose coupling has been an important design goal since structured design and information hiding were introduced a generation ago. Essentially, services interact on the basis of their external specification, sometimes referred to as their "contract." That is, service providers and service consumers don't depend on the inner workings or structures of the other.

What SOA Can Do For You
Irony abounds as SOA concepts not relevant outside of IT drive benefits relative to forces outside of IT, the forces that indirectly pressure IT via business requirements. Recall that IT agility is the secret to dealing with such requirements.

The SOA one-two punch of leveraging services that align more closely with business processes and then composing them in a more flexible manner means IT can be more responsive to changes in the business. This is good news for both Business Requirements Present and Business Requirements Future.

Business requirements are more easily accommodated because IT services more closely resemble business processes and loosely coupled applications are easier to modify independently of each other. So, applications tend to require less change and changes tend to be more self-contained. For these reasons, business changes are less likely to violate IT design assumptions, leading to greater IT agility.

The converse is also true. Technical changes to the IT model are less likely to adversely impact the business, leading to greater opportunities for efficiency.

Hey, What About Reuse?
Often, SOA discussions drift into the related topic of web services and the anticipated benefit of reuse. While web service standards are not a requirement for an SOA, their wide adoption has driven much of the recent surge in SOA implementations. Adherence to these standards, along with other SOA practices such as loosely coupling, makes reuse of services more feasible from a technical standpoint.

Of course, you will only gain reuse when you have overlapping requirements. Still, when these conditions occur, repurposing service-based software components typically involves less effort. This is a real benefit, but unfortunately, it can only accrue where requirements converge - and those circumstances do not arise as frequently as is often imagined that they will.

What You Can Do for SOA
"Spirit!" he cried, tight clutching at its robe, "hear me. I am not the man I was. I will not be the man I must have been...I will live in the Past, the Present, and the Future!" Scrooge repeated, as he scrambled out of bed. "The Spirits of all Three shall strive within me."

If SOA is to become a reality for IT, the change must also come from within. A detailed SOA implementation plan is beyond the scope of this article. However, we will provide a general overview of where to devote what kind of effort. Recall from Figure 1 that IT is defined in terms of people, process, and technology.

People, processes, and infrastructure technology should be addressed from an SOA execution standpoint. That is, directly change them to accommodate SOA. Applications, on the other hand, should be addressed from an SOA planning standpoint. That is, understand what aspects of the applications need to be changed to accommodate SOA and have a strategy to service-enable them. However, only execute that strategy and actually change applications as a result of user requirements managed by appropriate governance processes.

"People change" means developing skills in terms of SOA technologies, design approaches and testing discipline. It also can include organization structures. Often concentrating specialized skills in a "competency center" or "center of excellence" makes them more effective.

"Process change" includes governance that directs SOA investments where they are most likely to yield future benefit. This means anticipating requirements for flexibility or potential reuse, where SOA is more likely to be beneficial, as opposed to blindly applying SOA in every scenario. "Process change" also includes resource management to ensure that appropriate skill sets are available to project teams. This, by the way, is also a far more effective mechanism to ensuring SOA adoption and deriving SOA benefits than having an SOA police squad monitor projects for compliance.

Infrastructure technology consists of the shared IT assets needed to allow services to interact in a manner that meets business requirements. Infrastructure technology change typically includes the introduction of an Enterprise Service Bus (ESB) as described below.

An ESB is a key enabler for SOA, providing consistent deployment of Web Services, scalability, a central point for management and monitoring, meta data management, security and logging. It also facilitates an incremental service deployment strategy, allowing for coexistence with application integration based on previous technology.

Now consider applications. Much to the distress of the IT organizations that end up supporting them, IT has only limited influence over applications and their SOA capabilities. For COTS and SaaS-based applications, selection is driven by business requirements, with SOA and other technical considerations secondary at best. Remember, users don't care about no stinking SOA. For legacy applications, re-engineering them to be SOA-capable in the absence of project requirements is a dubious strategy unless these applications are expected to be significantly reused or extensively modified. Such scenarios are possible, but not typical.

This recommendation means SOA should impact applications indirectly, as a result of current requirements-related governance processes following planned application-specific service-enablement strategies.

Scrooge was better than his word.  He did it all, and infinitely more.

So can IT.

Sometimes change can seem as scary as being haunted by three spirits, but at the end of the day, such a recalibration of people, processes and technology is necessary to deal with the pressures of the current IT environment.

Pressure is not such a bad thing anyway. In culinary circles, pressure cooking is well known for reducing cooking time, using less energy, reducing the risk of food-borne toxins and improving flavor and nutrition.

IT would be well served by analogous benefits and SOA-based approaches can help channel these pressures to such productive ends.

Bon App IT.

References

• Dickens, Charles.A Christmas Carol in Prose, Being a Ghost Story of Christmas (commonly known as A Christmas Carol). London: Chapman and Hall. 1843.