In both our Licensed ZapThink Architect Boot Camp as well as our newer SOA and Cloud Governance Course, we also point out how governance typically involves human communication-centric activities like architecture reviews, human management, and people deciding to comply with policies. We point out this human context for governance to contrast it to the technology context that inevitably becomes the focus of SOA governance in the narrow. There is an important technology-centric SOA governance story to be told, of course, as long as it’s placed into the greater governance context.

One question we haven’t yet addressed in depth, however, is how these two contrasts — narrow vs. broad, human vs. technology — fit together. Taking a closer look, there’s an important trend taking shape, as organizations mature their approach to SOA governance, and with it, the overall SOA effort. Following this trend to its natural conclusion highlights some important facts about SOA, and can help organizations understand where they want to end up as their SOA initiative reaches its highest levels of maturity.

Introducing the SOA Governance Grid
Whenever faced with to orthogonal contrasts, the obvious thing to do is put them in a grid. Let’s see what we can learn from such a diagram:

The ZapThink SOA Governance Grid

First, let’s take a look at what each square contains, starting with the lower left corner and moving clockwise, because as we’ll see, that’s the sequence that corresponds best to increasing levels of SOA maturity.

1. Human-centric SOA governance in the narrow

   As organizations first look at SOA and the governance challenge it presents, they must decide how they want to handle various governance issues. They must set up a SOA governance board or other committee to make broad SOA policy decisions. We also recommend setting up a SOA Center of Excellence to coordinate such policies across the whole enterprise. These policy decisions initially focus on how to address business requirements, how to assemble and coordinate the SOA team, and what the team will need to do as they ramp up the SOA effort. The output of such SOA governance activities tend to be written documents and plenty of conversations and meetings.

   The tools architects use for this stage are primarily communication-centric, namely word processors and portals and the like. But this stage is also when the repository comes into play as a place to put many such design time artifacts, and also where architects configure design time workflows for the SOA team. Technology, however, plays only a supporting role in this stage.

2. Technology-centric SOA governance in the narrow

   As the SOA effort ramps up, the focus naturally shifts to technology. Governance activities center on the registry/repository and the rest of the SOA governance gear. Architects roll up their sleeves and hammer out technology-centric policies, preferably in an XML format that the gear can understand. Representing certain policies as metadata enables automated communication and enforcement of those policies, and also makes it more straightforward to change those policies over time.

   This stage is also when run time SOA governance begins. Certain policies must be enforced at run time, either within the underlying runtime environment, in the management tool, or in the security infrastructure. At this point the SOA registry becomes a central governance tool, because it provides a single discovery point for run time policies. Tool-based interoperability also rises to the fore, as WS-I compliance, as well as compliance with the Governance Interoperability Framework or the CentraSite Community become essential governance policies.

3. Technology-centric SOA governance in the broad

   The SOA implementation is up and running. There are a number of Services in production, and their lifecycle is fully governed through hard work and proper architectural planning. Taking the SOA approach to responding to new business requirements is becoming the norm. So, when new requirements mean new policies, it’s possible to represent some of them as metadata as well, even though the policies aren’t specific to SOA. Such policies are still technology-centric, for example, security policies or data governance policies or the like. Fortunately, the SOA governance infrastructure is up to the task of managing, communicating, and coordinating the enforcement of such policies. By leveraging SOA, it’s possible to centralize policy creation and communication, even for policies that aren’t SOA-specific.

   Sometimes, in fact, new governance requirements can best be met with new Services. For example, a new regulatory requirement might lead to a new message auditing policy. Why not build a Service to take care of that? This example highlights what we mean by SOA governance in the broad. SOA is in place, so when a new governance requirement comes over the wall, we naturally leverage SOA to meet that requirement.

4. Human-centric SOA governance in the broad

   This final stage is the most thought-provoking of all, because it represents the highest maturity level. How can SOA help with the human activities that form the larger picture of governance in the organization? Clearly, XML representations of technical policies aren’t the answer here. Rather, it’s how implementing SOA helps expand the governance role architecture plays in the organization. It’s a core best practice that architecture should drive IT governance. When the organization has adopted SOA, then SOA helps to inform best practices for IT governance overall.

   The impact of SOA on Enterprise Architecture (EA) is also quite significant. Now that EAs increasingly realize that SOA is a style of EA, EA governance is becoming increasingly Service-oriented in form as well. It is at this stage that part of the SOA governance value proposition benefits the business directly, by formalizing how the enterprise represents capabilities consistent with the priorities of the organization.

The ZapThink Take
The big win to moving to the fourth stage is in how leveraging SOA approaches to formalize EA governance impacts the organization’s business agility requirement. In some ways business agility is like any other business requirement, in that proper business analysis can delineate the requirement to the point that the technology team can deliver it, the quality team can test for it, and the infrastructure can enforce it. But as we’ve written before, as an emergent property of the implementation, business agility is a different sort of requirement from more traditional business requirements in a fundamental way.

A critical part of achieving this business agility over time is to break down the business agility requirement into a set of policies, and then establish, communicate, and enforce those policies — in other words, provide business agility governance. Only now, we’re not talking about technology at all. We’re talking about transforming how the organization leverages resources in a more agile manner by formalizing its approach to governance by following SOA best practices at the EA level. Organizations must understand the role SOA governance plays in achieving this long-term strategic vision for the enterprise.

Read more at: ZDNet

One of the frequently repeated complaints we’ve heard over our past nine years is that the IT department is increasingly non-responsive to changing business needs. Complexity, fragility, unpredictability, and unreliability all conspire to turn even the simplest of business requests for IT capabilities into a months-long, expenditure-heavy activity. And until very recently, there was really very little that the lines of business could do about that. Every business-IT interaction becomes a negotiation, with business trying to wrangle as much functionality as the time and budget would allow, and the IT department trying to limit new requirements so as to maximize the impact on an already over-stretched infrastructure.

As we discussed in our SOA: Enabling the Long Tail of IT ZapFlash, one of the roles of Service-Oriented Architecture (SOA) is to change this sad reality by enabling business user empowerment of a sort we have not seen before. But, the purpose of this ZapFlash is not to iterate again on that point. The main issue we are seeing now is that far too many companies still see SOA as a luxury that they can afford to postpone in tough economic times. Looming on the horizon, however, are a variety of technology and cultural changes that are combining to force rapid change in the IT industry. The amazing and rapid evolution of online IT capabilities is now conspiring to put the very future of the IT department in question as users become empowered to solve their own problems without involving the IT department within the enterprise. As we first stated in 2006, IT must Service-orient and empower their users or be doomed. This is not hype or hyperbole — this is now a reality for IT. Those companies resisting SOA will undoubtedly put the nails in their own IT coffins.

“You, IT, are Competing with the Cloud”
Last week, I recorded a podcast with Dana Gardner and a few other notable analysts and experts as part of the thought-provoking Briefings Direct series. In the podcast, which will be published in a few weeks, I discussed that individuals now have so much capability available to them through Web 2.0, Software-as-a-Service (SaaS), and Cloud-based applications that they can not only develop significantly powerful applications, but do so faster, with better quality, and less costly than they can do so within their own IT departments. In fact, many of these web-based applications are targeted to relatively non-sophisticated users with simple interfaces that empower users to develop complex applications without having to know how to code. In that podcast, I asked, “At what point does the line of business get frustrated enough with the cost and complexity of their own IT departments that they resolve their problems using capabilities outside the network rather than inside. Is the IT department in danger of becoming obsolete?”

To further reinforce that point, ZapThink recently attended two major vendor events: IBM’s IMPACT 2009 and Software AG’s SOA Summit 2009, with speakers that quite coincidentally echoed the above sentiment. At IBM’s event, a number of speakers made the point that the potency provided by Cloud Computing capabilities enables business users, not career technologists, to develop very sophisticated applications at remarkably low costs due to the pay-as-you-go model and virtualization of IT resources. Even more remarkably, at Software AG’s SOA Summit, Kevin Flowers, Director of Enabling Technology at Coca-Cola Enterprises stated in stark terms that “you, IT, are competing with the Cloud.” What he meant was that the “cloud” (which in his terms referred to the general capabilities of Web 2.0, SaaS, and Cloud Computing as a whole) provided such tempting capabilities that if the IT department can’t rise to the challenge and equally empower its users, the users will go elsewhere to get their needs met at potentially greater quality, lesser cost, and in shorter time.

Enable User Empowerment … or your Users will go Elsewhere
Now, this vision of the self-empowered business user is still a ways off given security, privacy, and access to local data concerns, but these challenges are purely technical. The real issue is an organizational one: will a business audience already fed up with IT’s inability to meet business imperatives authorize their non-IT users to get their needs met by outside providers? If so, Cloud, SaaS, and Web 2.0 companies will quickly rise to the challenge (and newfound revenue streams) and solve the aforementioned technology challenges much faster than the IT department can react to the threat. Therefore, it makes sense to revisit two themes that are a persistent thread in ZapThink conversations: using SOA as a means to enable business empowerment, and dealing with the rapidly emerging “digital divide”.

On the first note, we must re-emphasize the point that it is not IT’s role to own and manage the applications on behalf of the business. Rather, its role is to enable business users to consume and compose a wide array of Services that IT manages as simply as possible. Enlightened IT organization should see emerging Web 2.0 / SaaS / Cloud (“Cloud in the large”) capabilities offered by third-party vendors both as a source of opportunities for Service deployment and consumption as well as competition. Every evolution and advancement of the Cloud in the large raises the bar for what is expected of internal IT capabilities. To respond to this reality, the IT department must stop its incessant focus on the “T” in information technology and redouble its efforts on the “I” part. This means that the focus on abstract, easy-to-consume, easy-to-compose Services is more important than ever and is the primary goal of IT, rather than a nice-to-have addition.

In addition, we continue to remind companies that the IT experience that their business people experience away from the office — on their handheld devices, Internet browsing experience, and other devices — is rapidly becoming more sophisticated and powerful than their enterprise IT experience. This is the true “digital divide” that we often refer to in our conversations with end users. Indeed, the enterprise IT experience is downright embarrassing. Why is it that when we’re at home we get the luxury of using apps as sophisticated as Facebook, iPhone, Tivo, and Google Docs, while at work we have to suffer decades-old user interfaces and frustratingly unproductive experiences? This rapidly widening digital divide between the IT-at-home and the IT-at-work experience is threatening to once and for all put IT on the much-deserved defensive and justify its millions of dollars of expenditure for systems that pale in usability comparison against those that are either free or cost pennies on the enterprise IT expenditure dollar.

The ZapThink Take
As Miko Matsumura, Deputy CTO of Software AG put it at Software AG’s SOA Summit 2009, “evolution is about survival.” SOA, along with Cloud and other emerging architectural approaches to agility, represent an evolution in the way that users work with IT assets. But, the entire purpose of evolution is to avoid a certain death. Organisms evolved to deal with environmental realities that, without their evolution, would have meant their extinction. Likewise, organizations need to evolve to deal with the reality of the IT landscape that requires agility to avoid a certain death. From this perspective, if the business finds that they can get their IT needs met without the IT organization’s involvement, the IT organization will die. IT without business support is an impossibility.

Trying to avoid, deny, restrain, or otherwise negate the inexorable march to Service-oriented, user empowered IT is an exercise in futility. Those organizations that think they can successfully survive in this new environment by canceling their SOA projects are stringing their own nooses. CIOs who are so short-sighted to believe that the business will accept the current inefficient, inflexible, expensive, unreliable, and unpredictable IT systems of today while ignoring the obvious alternatives should be strung up on the nooses they have set up for themselves. While technology challenges remain to make the vision of agility an uncontestable reality, technology challenges are the easiest of all to solve. When the business begins to express their desires, will the IT organization rise to the challenge or face inevitable demise?