TOGAF, COBIT and the governance and management of open-source software
May 14, 2013 —
(Page 1 of 2)
Related Search Term(s): COBIT, open source, TOGAF
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.