Whether the process is driven by formal SOA principles or by combining Web, application and database tools to create a customer portal, IT professionals are confronting a world of multi-component applications. These components are often used several times in more than one application, meaning simple
To address governance for multi-component applications, IT pros have to start with a component-based governance model, create a dependency tree driven by application lifecycle management (ALM), structure governance practices, and select tools that align with this component-based framework.
Most IT governance is based on a vertically integrated multi-layer model, like that used by Federal IT. The model starts with strategic/business goals and moves downward to tactical/operational goals set in functional areas, which includes IT and IT support for line operating groups. In most cases, this framework is suitable to frame governance for multi-component applications, at least down to the functional/operational layer. In fact, any dependencies on application design/structure at that level would be an indicator that the governance plan was designed incorrectly; implementation details should not appear at the requirements level. The trick is to align the functional/operational goals with both components and applications.
It's nearly impossible to set meaningful governance goals for components that are designed to be reused, since most companies deploy applications to support operating missions. Even a multi-component application will inherit its compliance goals from the functional/operational layer of the compliance plan. These goals then devolve on the components.
What's different in componentized applications is that every component inherits compliance requirements from every application in which it's used. This is the critical additional dimension in compliance management for modern software.
Compliance in multi-component apps
The main compliance challenge created by multi-component applications is that changes are made to components and not whole applications. New components can be added to an application and can immediately change governance requirements or create issues.
Every component inherits compliance requirements from every application in which it's used.
When software changes are made to components, the changes have to be reflected in governance practices in every application that the component is used with. To capture these changes and address them in compliance/governance, it's critical to incorporate governance goals inherited from applications to components into the component-level ALM processes.
The easiest way to address the problem of component changes impacting governance practices is to develop a graph/tree that relates components to applications and governance at the functional/operational level. Since effective ALM for multi-component applications has to reflect the component makeup of every application, it should be easy to get information from the ALM procedures in place.
Once a graph of component/application relationships is linked to the governance policies at the functional/operational level, it's possible to assess every component change and relate it to the governance policies that could be impacted. If you start with a graph and simply draw a line from a component upward through the applications that include it, to the functional/operational level of your governance plan, you'll identify applications and practices that are impacted and know where to start validating the goals and compliance impacts of the changes.
Extensive componentization will likely drive at least some changes in governance upward through the traditional governance model. This means when you're considering governance tools for componentized applications, it's critical to look not for point-solution tools to address microcosmic pieces of the puzzle, but governance architectures that can address the entire governance structure holistically.
SOA-compatible governance tools
IBM, Oracle and SOA software provide well-known SOA-compatible governance suites. The Open Group SOA Governance Reference Model (SGRM) is a good architecture to guide tool selection for SOA componentization. SGRM principles can be applied to non-SOA componentization, but it's important to check how any governance tool will work if applied to such applications.
The biggest issue with governance tools for components not built according to SOA principles is that Web Services Description Language (WSDL) won't be examined to establish component functionality and interfaces, and to help identify application component makeup. This is another reason why linking componentization governance to ALM policies may be absolutely critical.
ALM policies serve as a means of centralizing information on components and component reuse among applications, which is essential information in both gathering governance requirements and tracking governance impacts of component changes. If you are relying on non-SOA (RESTful) componentization, ALM is your opportunity to fill in what will otherwise be a serious governance gap.
For those looking for automated support to multi-component governance that must accommodate a large population of non-SOA components, the best approach is to look at the integration of ALM policies and DevOps tools. Popular DevOps tools Puppet and Chef can be used to automate ALM processes.
If models/scripts are designed to document and enforce component relationships to applications, they can be used to maintain enough information on componentization -- even for non-SOA components -- to provide a link to governance. It's likely that proliferation of componentized applications built on a Web model (RESTful) -- rather than a SOA model -- will encourage a wider choice in tools as well as more specialized governance aids over time.
Multi-component architectures are in a state of flux as the Web model of stateless, loosely coupled, components takes hold in enterprise applications. Mobility and the cloud will likely accelerate these changes.
Those who believe SOA frameworks alone will solve multi-component governance issues will be increasingly disappointed. By starting with current governance models, working through SOA governance architecture like SGRM, and adapting to Web-model componentization through ALM and DevOps, an IT architect can manage the present and prepare for the future at the same time.
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
This was first published in July 2013