When I teach classes on governance, I ask the class this: If you were newly made manager of something—security, change or problem management, or any of the COBIT processes—and you had a “greenfield,” what would you do first in the planning1 phase? Typically, the range of answers is wide, but the responses usually start with “fix processes” or “create a strategy.” I try to walk students from vision down. When I get to strategy, I ask, “What is the next thing you need to produce?” (Hint: It is the next process in COBIT after APO02 Manage strategy.) I tell students that it is a long word and it starts with the letter A. I typically get answers such as “assessment,” “assurance” and “assertion,” among others. Fortunately, I have never gotten “antidisestablishmentarianism.” Occasionally, someone says “audit,” and I tell them that “audit” is not long unless you are the one being audited. The word I am looking for is “architecture.”
Since architecture is often forgotten, it is worth talking about. Of course, COBIT calls out architecture with APO03 Manage enterprise architecture. The documented process lists the expected IT-related goals:
- Alignment of IT and business strategy
- IT agility
- Optimization of IT assets, resources and capabilities
As usual, COBIT offers really good strategic advice. But you need more.
As with every other process, you need a governing body, which we will call the Architecture Review Board. The review board sets principles and policies based on executive direction.
Enterprise architecture as a practice defines the structure and operation of an organization with the intention of determining how an organization can most effectively achieve its current and future objectives.To manage COBIT enterprise architecture to deliver on the direction, you need enterprise architects (EAs), solutions (SAs) architects and technical architects (TAs). The EA describes the enterprise in terms of its business entities, their properties, and the relationships between them and the external environment to ensure everything comes together seamlessly. Enterprise architecture as a practice defines the structure and operation of an organization with the intention of determining how an organization can most effectively achieve its current and future objectives. The EA looks across the organization’s programs to ensure that the enterprise as a whole has integrity and consistency. However, the EA cannot possibly take into account the level of detail necessary to build something, so the EA will delegate all but policy-level decisions to specialists assigned to a particular workflow or application. Without starting a bun fight, I want to state that the enterprise IT architect (EITA) is a specialized EA, who is concerned with the holistic view of information and technology enterprisewide.
The SA is assigned to a particular enterprise project or program to ensure technical integrity and consistency of the solution during the life cycle phases. SAs are involved with all aspects and activities of an initiative: from concept definition through requirements analysis and implementation, to IT operations handover and ongoing maintenance. Consequently, an SA is a sort of generalist contributing positively to all these activities. Solution architecture as a practice defines and describes the system delivered in the context of a specific solution and may embrace description of the entire system or only its constituent parts. Security, unfortunately, is often thought of as a specific solution or constituent part. For you familiar with ISO/IEC 27001 and ISO/IEC 27002, the SA is akin to what the International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) calls a secure systems engineer (refer to clause 14.2.5).2
The TA primarily focuses on a particular implementation technology. The technology, such as Java, is most likely employed across many enterprise solutions. TAs usually have some hands-on involvement in the delivery, provide technical leadership for development teams, and define standards and practices. Technology architecture as a practice develops methodical specifications, models and guidelines using standards such as Fundamental Modeling Concepts (FMC)3 and Unified Modeling Language (UML)4. The TA follows formal and informal solution, IT and enterprise architecture processes. Typically, a TA specializes and you will see that reflected in the name of the role, e.g., Java Architect, .NET Architect, Infrastructure Architect.
At the end of the day, the EA defines what problems need solutions, the SA translates a problem into a solution and the TA works within a solution. Now you just need to study The Open Group Application Framework (TOGAF)5, Sherwood Applied Business Security Architecture (SABSA)6 or Microsoft Certified Architect (MCA)7 depending on your preference.
Peter T. Davis, CISA, CISM, CGEIT, COBIT Foundation, COBIT Implementation, COBIT Assessor, COBIT INCS, CISSP, CPA, CMA, CMC, ITIL FC, ISO 9001 FC, ISO 20000 FC/LI/LA, ISO 27001 LI/LA, ISO 27005/31000 RM, ISO 27005 Lead Risk Manager, ISO 28000 FC, ISO 31000 Lead Risk Manager, ISTQB CTFL, Lean IT FC, Open FAIR FC, PMI-RMP, PMP, PRINCE2 FC, SSGB, RESILIA FC
Is the principal of Peter Davis+Associates, a management consulting firm specializing in IT governance, security and audit. He currently teaches COBIT 5 Foundation/Implementation/Assessor, ISO 27001 Foundation/Lead Implementer/Lead Auditor, ISO 31000/ISO 27005 Risk Manager (RM), ISO 20000 Foundation/Lead Implementer/Lead Auditor, ISO 22301 Foundation, ISO 9001 Foundation and Project Management Institute Risk Management Professional (PMI-RMP) courses.
Endnotes
1 You may use Plan-Build-Run-Monitor (PBRM), Plan-Do-Check-Act (PDCA) or Planning-Organizing-Staffing-Directing-Controlling or some other model. Planning is planning.
2 Security engineering is defined as “the practice of building information systems and related architecture that continue to deliver the required functionality in the face of threats that may be caused by malicious acts, human error, hardware failure and natural disasters.” Certified Information Systems Security Professional (CISSP) Candidate Information Bulletin, 15 April 2015
3 Fundamental Modeling Concepts
4 Unified Modeling Language
5 The Open Group Architecture Framework
6 Sherwood Applied Business Security Architecture
7 Microsoft Certified Architect