BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles How SOA Governance (and SOA Management) Should Actually Be Done

How SOA Governance (and SOA Management) Should Actually Be Done

Bookmarks

In my last article, I explained how the industry is doing SOA all wrong, through its focus on simplistic and wrongheaded design principles (such as “Avoid point-to-point connections”) and the neglect of what should be the core concern, namely dependencies between systems.

The problems with SOA practice, in fact, go much deeper. They involve fundamental issues of governance and management. Even the organizations considered most mature in terms of SOA capability don’t get it right. I have worked at organizations with control bodies variously named “SOA Centre of Excellence” and “Integration Centre of Competence”, and have found them to be largely ineffective. They tend to be staffed almost exclusively by technologists, with business representatives attending meetings only as occasional guests. Consequently, the topics they deal with are limited to technology, and a narrow subset of technology to boot. The activities they tend to focus on are low-level and far downstream of the decisions that really matter. A lot of their activity also seems aimed at reining in rogue projects and re-establishing their authority over them, and they generally seem to be scrambling to stay on top of all the business initiatives that impact on their perceived area of responsibility.

As an industry, we ought to be doing better than this.

My first criticism of industry practice in the areas of governance and management is that it tends to be technology-focused. The very term “SOA governance” is widely understood to mean the governance of the SOA practice, which is seen as an IT function.

But SOA is much more than technology! It is an organizing principle for the enterprise as a whole. My view is that “SOA governance” does not mean the governance of SOA any more than “scientific thinking” means “thinking about science”. We recognize that “scientific thinking” means the application of science to thinking, not the other way around. In similar fashion, “SOA governance” should mean the application of SOA thinking to governance.

(What exactly does this mean? How does one “think SOA”? I’ll come to these questions in a moment.)

My second criticism relates to the widespread confusion between the terms “governance” and “management”. These terms tend to be used interchangeably, and most people, even in SOA governance roles, can’t seem to explain the difference. There is, however, a crucial difference between the two functions. Both are important, but they require different perspectives and different practices to execute them effectively.

The definitions are simple and obvious in hindsight:

  • Governance is about doing the right things
  • Management is about doing things right

In other words, governance is about the ends, or the “what”. Management is about the means, or the “how”. Confusion between these two aspects can lead to suboptimal control systems, and this is indeed what I have seen in the industry today.

Organizations do have well-defined separation of governance and management functions in general, but this wisdom seems to be absent when dealing with SOA. After all, the board of directors and the executive management team look at the “what” and “how”, respectively, of everything the organization does. Similarly, project steering committees and working groups do the same at lower levels.

So what about SOA governance (and SOA management)? Why is there so much confusion and conflation between these two functions? Shouldn’t it be just a simple matter of extension, based on what we know about SOA and about the functions of governance and management?

That is precisely how the dependency-oriented method approaches these definitions. We know from the previous article that SOA is best seen as the science of analyzing and managing dependencies between systems, where “managing dependencies” means eliminating needless dependencies and formalizing legitimate ones into stable and well-understood contracts.

SOA governance is therefore the set of practices that establish what dependencies are legitimate and what existing dependencies fall outside of this set. SOA management deals with how to remediate illegitimate dependencies, how to formalize legitimate ones into contracts, and how to prevent recurring violations.

The diagram below illustrates this model in a nutshell.

Viewed in this light, the activities of most SOA Centres of Excellence can be seen to be rather narrow and limited in scope. This diagram shows just how small a subset of its role is actually performed by such a body.

My third criticism of the SOA governance function (which is usually management rather than governance!) is that it is too heavyweight and wastes resources on needless activities.

What I am going to describe here is a control system that addresses all of these criticisms. It will apply to all levels of the enterprise, not just to technology. It will clearly demarcate the functions of governance and management. And it will provide a lightweight method (a set of roles, bodies, processes and checklists) that can potentially replace the existing control systems in an organization.

Of course, an article of this size cannot do justice to the method, so I will merely touch upon its salient features and refer you to my book “Dependency-Oriented Thinking: Volume 2 – Governance and Management” for more detail.

Organizational Roles

An all-encompassing control system necessarily involves roles from both the business and technology sides of the organization, and all levels from executive management to operations. However, the key role is to be played by enterprise architecture. Enterprise architects must champion the dependency-oriented approach and drive its adoption by all other stakeholders, as the following diagram shows.

Traditionally, business executives have focused on objectives, strategies and high-level business processes. The culture of dependency analysis exists only partially and in specific pockets, usually through the risk management function. Similarly, IT practitioners have traditionally focused only on techniques to implement business logic in the most cost-effective way. Formal dependency analysis does not form part of any structured software development method, mainly because many dependencies flow from business requirements, which are considered to be above question, Besides, fresh dependencies are often introduced by technologies themselves, and this is a major IT blind spot.

It is only the enterprise architecture function that has a sufficiently broad and long-term vision about both the business and technology sides of an organization. Dependencies are a familiar concept for architects (even if they have hitherto never been promoted to a top-of-mind consideration). Therefore, it is only enterprise architects who can introduce a dependency-oriented culture into the way the organization functions.

Governance and Management Bodies

Depending on the size of the organization, the number of bodies required to oversee both governance and management functions could vary. However, the key principle to remember is that the same body must never be tasked with both governance and management, as this conflation of roles dilutes focus and reduces the effectiveness of both functions.

The entities at each layer of the organization require to be analysed using a specialised set of skills, and therefore the composition of the dependency committees will be different at different layers. There may be overlaps, as when some individuals have membership in more than one committee. But that is likely to be the exception rather than the norm. It is usually only enterprise architects who will have visibility across different committees and can bring about coherence in their direction and functioning.

Processes

Governance and management processes need to be embedded within the larger set of BAU (Business As Usual) activities of an organization. The focus, of course, is to ensure that only legitimate dependencies exist between systems at every level of the enterprise (and are formalized into stable, well-understood contracts), and illegitimate dependencies are eliminated.

The following diagrams show the processes that an organization needs to implement, both in the initial stages of moving to Dependency-Oriented Thinking and later on, when systems and processes are mature.

The boxes in blue above represent business processes that exist in organizations to introduce new business initiatives. The dependency-oriented method seeks to weave dependency-related tasks into this process. A one-time review of dependencies will bring forth a set of remediation tasks that need to be prioritized and funded just like regular business initiatives. At the same time, new business initiatives need to be subjected to dependency analysis and suitably modified before they are implemented.

Once the organization reaches “steady state”, i.e., there are no outstanding dependencies to be remediated, the set of processes becomes much simpler. Then, only new initiatives need to be reviewed from a dependency perspective before they are implemented, and this culture should become part of the organization’s DNA.

Checklists

To make the tasks of governance and management bodies easier, a set of simple checklists needs to be developed at different layers of the organization as required. The broad areas of concern that these checklists will cover are summarised below.

The following table lists some sample governance questions.

The following table lists sample management questions.

Each layer of the organization (business, applications, information (data) and technology) necessarily has to deal with a different set of entities, and the dependency-related questions that need to be asked at each layer will therefore be specific to those entities. It is the job of the dependency governance and management committees at different levels to formulate and apply these checklists of questions.

Summary and Conclusion

In sum, the practice of SOA in the industry is due for an overhaul, both in the areas of analysis and design, and in the areas of governance and management. Dependency-Oriented Thinking is a comprehensive method for forward-looking organizations that wish to realise SOA’s promise of greater business agility, sustainably lower operating costs and reduced operational risk.

For a more in-depth look at Dependency-Oriented Thinking, read the eBook: Dependency-Oriented Thinking: Volume 2 – Governance and Management.

About the Author

Ganesh Prasad has 27 years of IT experience and has been a developer and application designer through four generations of technology - mainframes, minicomputers, client-server and the web. His experience as an architect over the last 10 years, especially in the Shared Services area, has led him to pioneer radically simpler and less expensive alternatives to traditional corporate IT strategy.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT