The Butterfly Effect is a principle of chaos theory that states that small differences in the initial conditions of a system can lead to dramatic variations in the future behavior of that system. As there is little in this world as chaotic as today's information technology (IT)-dependent enterprises, it should come as no surprise that small variations in the decisions of the business can lead to dramatic, unexpected effects in the world of IT. As long as the lines of communication between IT and business remain within the largely manual sphere of phone calls, faxes, and emails, the Butterfly Effect rarely presents a problem. However, the more effectively IT provides business decision makers with the tools they need to make and communicate decisions in an automated fashion, the more likely it is that some inadvertent action on the part of an unsuspecting business manager will lead to unexpected, potentially dangerous effects on IT.
Service-Oriented Architecture (SOA), of course, is an approach for organizing IT resources so that the business is better able to take advantage of those resources in a flexible, essentially automated fashion -- an approach that manifestly increases the chances of the Butterfly Effect. The possibility that increased business agility might actually lead to new risks presents an interesting irony. After all, we frequently caution architects about the risks of implementing SOA poorly, but the Butterfly Effect suggests risks inherent in implementing SOA properly. Fundamentally, SOA done right gives people greater power and flexibility, and as a result, an increased risk that they're really going to muck things up.
The Two Faces of SOA Governance
Fortunately, companies can take action early in their SOA implementations to prevent chaos from taking hold in their businesses. In general, the approach companies should take to prevent their employees from mucking everything up is to implement a governance framework, which provides an infrastructure for creating, communicating, and enforcing corporate policies across the organization. IT governance in particular is a hotbed of activity today, not only because it's vitally important for companies to govern their IT operations, but also because the business calls upon IT to provide governance tools to the business at large. As companies implement SOA, it's no surprise that Service-oriented approaches to IT governance increasingly receive the focus of attention.
There are two faces to SOA governance, however. On the one hand, SOA governance simply means governing a SOA implementation initiative -- for example, communicating corporate policies to developers implementing Services, and giving them the tools they need to follow those policies as they assemble the various elements of the SOA implementation. On the other hand, there's a broader, more strategic definition of SOA governance: IT governance in the context of SOA. After all, SOA isn't a single application that you can stick in a corner somewhere; instead, it's important to implement SOA as Enterprise Architecture, applying Service-oriented principles across the entire scope of interaction between the business and IT. As the ZapThink SOA Roadmap suggests, building a governance framework is a critical early milestone on the road to a successful SOA implementation -- not a governance framework for the SOA implem entation specifically, but rather, a framework that outlines governance best practices across the organization that will leverage the power and flexibility of the Services that form the core of the SOA implementation. The SOA Butterfly Effect, therefore, becomes an issue that companies can resolve by leveraging SOA governance best practices, as long as we use the broader, strategic definition of SOA governance.
The Butterfly Flaps Its Wings
Let's explore an example of the Butterfly Effect in action. Say, for an example, that an executive reviewing sales reports requires data that are more current than any available through the company's CRM system. In the traditional, pre-SOA world, the executive might call a data analyst in the IT department and ask for a current report using more recent data. The data analyst knows that the analytics software that generated the report leverages queries against a data warehouse, which only contains summary data as of the previous Saturday. However, the executive doesn't care about how the technology works and simply needs the report to make critical business decisions. In this case, the data analyst might figure out how long it will take to create, test, and run an ad hoc query against the live transactional systems, and translates this information into a request for additional funds and time to perform the request. The executive must now make an informed business decisi on about whether the report is important enough to warrant the time and expense to generate it.
Now, let's segue to the post-SOA scenario. In this situation, the executive in the same situation has a policy management tool accessible via a corporate portal. This tool leverages several Services that form part of the SOA governance framework, but the executive is none the wiser about these technical details; all managers need to know is that they have the authority to change certain corporate policies via the corporate portal. As such, the exec can go into the portal and adjust the Service-level agreement (SLA) for corporate reporting that includes the required report, changing the turnaround time for corporate data from "up to one week" to "up to one day," through the click of a button.
Now IT has a problem, as the Butterfly Effect takes its toll. Will the IT infrastructure be able to respond to the executive's change automatically, or will it require manual intervention by the IT staff? Will IT simply fail to satisfy the new SLA? Even worse, what if different executives have entered more than one policy change during the same period of time? Which one should IT address first? In the pre-SOA world, the lack of automation required humans in the loop on changes that affected IT, so there was always the possibility that human judgment could be brought to bear in the case of business changes with unexpected consequences. As SOA governance leads to more automated policy management, however, companies run the risk of automating human discretion out of the policy implementation process, to their peril.
Meta-Policies to the Rescue
Fortunately, once companies become aware of the Butterfly Effect problem, the solution is relatively straightforward. Clearly, there must be a distinction between the policy changes that the business may implement on their own, and policy changes that must require (manual) IT approval. In other words, SOA governance not only requires the management of policies, but the management of policies about policies -- what you might call meta-policies. Such meta-policies might be boundary conditions on allowed policy changes. For example, a meta-policy might state that authorized business managers may change a policy threshold value up to 10% in either direction without requiring IT approval, but any changes greater than 10% must go through a particular IT manager first.
As a result, there's no such thing as a fully automated governance framework. At some point, humans must directly manage policy change. This limitation doesn't constitute a policy shell game, however, as effective SOA governance tools will provide greatly increased automation and flexibility in how companies create, communicate, and manage their policies. But as with any powerful tool, people must know what they're doing when they use it, and wield it carefully. Another important lesson that the Butterfly Effect teaches is that IT must have the appropriate managing authority in place to make the necessary judgment calls on meta-policies. After all, if the IT manager responsible for approving a policy change doesn't understand the implications of that change, then the core problem remains.
The ZapThink Take
When a company has implemented SOA, the IT managers responsible for approving policy changes must have a broad understanding of the interdependencies of the various elements of the architectural implementation. In the pre-SOA example above, only the data analyst had to understand the cost and time implications of ad hoc data queries. In the post-SOA world, however, a policy change might impact multiple applications, data sources, and legacy systems. As a result, an analyst is unlikely to be the right person to make the call as to whether a particular policy change has unintended consequences. The correct person not only must have that broad understanding of IT, but must also be able to speak in business terms about the costs and benefits of complex policy changes. As a result, the Enterprise Architect may be the best person for the job.
