TOGAF, COBIT and the governance and management of open-source software

Industry pundits, application security professionals, development managers, developers and legal teams alike realize that the world has changed. Rather than writing code, developers assemble components, making them more productive personally and also enabling them to meet the better, faster, cheaper goals imposed by the companies they work for. And most organizations find out—like it or not—that their code under management is comprised north of 50% open—source components.

It seems that the use of open source, with faster, better, cheaper benefits and operational, security and intellectual property risk, ought to be addressed both in architecture and governance frameworks. How might an organization map the use of popular architecture and governance frameworks with the policies and processes necessary to govern and manage the use of open source? In order to accomplish this mapping, let’s consider extending the combined use of TOGAF and COBIT, two popular frameworks.

To put us all on the same page, let’s first align on a definition of architecture. Because I like standards, can we all agree to use the ISO/EID definition? “Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution (ISO/IED 42010).” So, it’s all about the structure of a system.

The Open Group Architectural Framework has evolved to help enterprise architecture structure architectural domains, including business, data, application and technology. If its use is successful, it informs the structure for enterprise architecture, and informs the processes and techniques around software development. It helps organizations avoid re-inventing the wheel, and as a vendor, tool and technology-neutral open standard, TOGAF can complement other frameworks.

Where does open source fit in? As described by Dave Lounsbury, CTO and Vice President of The Open Group, the considered use of open source fits in all four domains. In business architecture, requirements are defined and readiness for change is analyzed. In application architecture, component guidance is backed up by an audit and inventory. In data architecture, governance and project metadata are determined. And under technical architecture, technology opportunities are considered. Under these domains, governance, including capability and compliance assessments, is determined by an architecture board. Sounds great. And in fact, we’re getting close to addressing the business need, the “why this matters.” But how are key performance indicators determined, and broader IT governance and processes (including a broader set of stakeholders) established? If TOGAF supplies a methodology to add structure for enterprise architecture processes and technology, COBIT can help organizations implement TOGAF and connect it to other IT processes.

What of COBIT? Control Objectives for Information and Related Technologies is a framework created by ISACA for IT management and governance. With COBIT 5 (the latest version), ISACA has attempted to consolidate major ISACA frameworks and research, and to better align with other major frameworks (e.g. TOGAF, ITIL) and standards in the marketplace, with the goal of becoming an “overarching” framework enabling greater IT efficiencies. Essentially, according to Mauritz Kloppers, an independent IT management advisor, they’ve “harmonized practices and standards such as ITIL, ISO 27001 and 27002, and PMBOK.” In COBIT language, “The COBIT 5 goals translate stakeholder needs into specific, practical and customized goals within the context of the enterprise, IT-related goals and enabler goals.”

Relative to governing and managing the use of open-source components while addressing operational and security risk, I’ve found COBIT to be very useful by leveraging their “Risk IT Key Management Practices,” which is a combination of Evaluate, Direct and Monitor (EDM) processes for governance of enterprise IT and Align, Plan and Organize (APO) processes for management of enterprise IT. I simply extend these governance and management processes to govern and manage the use of open-source components. Similarly, they’ve established governance and management processes pertaining to enterprise architecture, and then tied practices to a RACI (Responsible, Accountable, Consulted, Informed) chart.

While TOGAF adds structure for enterprise architecture, processes and techniques, COBIT puts TOGAF into context by relating architectural processes to all other IT processes. And COBIT, through RACI charts, adds responsibilities for TOGAF, helping organizations implement TOGAF and connect it to broader IT processes. To complete the circle, COBIT also adds key performance indicators for TOGAF. Nice.

So what’s my beef? If open-source use is as prevalent as industry experts and your own open-source use analysis indicates, why aren’t these frameworks explicit in calling out the need for its governance and management? Rather than “extending” their use, shouldn’t these frameworks be explicit about addressing open-source project use?

Many would argue that open-source use has hit a “tipping point,” that it has helped accelerate the rate of innovation for mobile, cloud and Big Data, while affecting how individuals and organizations are creating software. The increased amount of co-opetition among organizations through the use of open source (see Lodestone, OpenMAMA, GENIVI) is another indicator of its industry acceptance and game-changing capability. In my view, COBIT’s Risk IT Key Management Practices should be explicit about risk from the use of open-source components, and these risks should be in scope. Risk factors, including loss of IP, security vulnerabilities, license conflicts and obligations, and export controls, need to be addressed directly.

And TOGAF should not just make an association, but be explicit in business architecture, application architecture, data architecture and technical architecture domains regarding the added benefits. These benefits and risks of open source can then “cascade” into the broader IT governance and management COBIT framework.

Phil Marshall is Senior Product Marketing Manager with Black Duck Software.