Many large IT organizations, and the software professionals within them, face issues of compliance/governance almost daily. They also face a continuing challenge in modeling IT evolution to match Business needs.

Service-oriented architectures (SOA) don't alter the principles of enterprise architecture (EA) or the essential requirements of IT governance, but they change the playing field. Professionals can harmonize EA and SOA to enhance both. If their EA program includes SOA-related functional hooks and consider the benefits of federated IT in focusing compliance requirements exchanges from EA to SOA, they can create a win-win.

 Mapping is the most important step in both securing EA benefits and starting SOA governance on the right footing.

EA's primary goal, from an IT perspective, is to align application capabilities with business requirements. In many cases, this goal is inhibited by monolithic application structures that can't easily be transformed as business needs change. SOA was framed in large part to break up applications into business-related functional components, so in theory it can facilitate achieving EA goals, but getting the most of the EA/SOA symbiosis requires looking at applications in a different light.

While EA methodologies like TOGAF have been adapted to embrace SOA, few enterprises actually map business needs directly to SOA components. This mapping is the most important step in both securing EA benefits and starting SOA governance on the right footing. Enterprises report that the critical issue at this point is a failure to align SOA components with EA-defined processes.

SOA componentization is more often structured along technology or software functionality boundaries than based on business processes. If that happens, SOA adoption worsens EA alignment with IT and virtually disconnects SOA governance from business needs.

To get EA and SOA into alignment, defining business information usage and needs more granularly than is typical should be the first step. The objective is to be able to define business-based componentization as the highest level of SOA componentization and to further segment components along technology boundaries as needed, retaining the original business-function relationship.

In most cases, the business-level components will be more virtual collections of actual SOA components than real software elements, creating a hierarchy of EA-business-process driven virtual components that cleanly divide into SOA components. This mechanism will provide the means of linking both business and IT migration needs directly to SOA components rather than to applications.

SOA and EA can also combine to facilitate taking an almost-componentized view of business-unit IT needs and then harmonizing them by federation up to the corporate level, a process usually called federated IT.

Many companies have abandoned a federated IT approach because they believed it was useful only when IT was almost autonomous per business unit, a rare structure today. In fact, there is evidence that adopting a federated view of IT in EA processes will help with SOA governance by making the information exchanges and process dependencies across business unit lines clearer.

Compliance goals for an entire organization can be parsed in two dimensions:
Across business units, where they can be used to guide governance as a process;Across business components, where they can guide SOA governance by driving compliance down to the component level.
Probably the most useful result of taking an EA-integrated and federated view of IT to create functional componentization for SOA is that the governance needs of SOA can be directly mapped to application lifecycle management. ALM in SOA can be challenging because the component reuse inherent in SOA can make traditional ALM management of dependencies more difficult; a component can drive changes across multiple "applications."

In a true SOA-based enterprise, it's possible to substitute the EA-derived business process components for the traditional applications in ALM, which have little meaning in a SOA-componentized world. Since these business process-based components align with EA processes that generate compliance requirements, the requirements can easily drive down to the SOA components within them. Because business-process alignment of SOA will also align SOA application changes with business unit operational processes, it's easy to integrate ALM and testing with the worker practices.

Businesses developing SOA applications internally will be particularly well-positioned to integrate EA insights into SOA governance. Not only will they have greater latitude in SOA componentization to facilitate the flow of governance requirements, they may be able to employ SOA design patterns to harmonize implementation practices and incorporate governance elements into component design.

Functional logging of key changes to create audit trails is a common requirement for governance. This can be incorporated directly into components that process critical information elements. Doing this reduces the risk that changes will bypass auditing, something that can happen with orchestrated SOA applications if workflows aren't managed properly.

IT governance is the process that aligns IT practices with principles of risk management and compliance. This leads to the question of the specific source of both standards and mechanisms to create the alignment. It's not enough to say, "Sarbanes-Oxley" or "ISO 9001;" you have to divide those requirements up among the business-to-IT-process mappings you've created.

This is where EA and SOA combined can be powerful. The alignments created in that first critical step should make it easy to identify specific compliance implications for every SOA component. This is achieved by relating that component to a business-componentized element and then relating the element back to its governance guidelines.

SOA breaks traditional application borders. If properly developed, EA can support any functional division of IT assets and link each component back to business needs. That's the prescription for effective compliance management. If the combination of tension and cohesion inherent in the EA/SOA relationship is managed correctly, it's a prescription that a thoughtful IT professional can easily adopt.