In the age of cloud, internal IT departments are being continuously challenged to demonstrate value and alignment to business requirements and business needs.
In Part 1 of Establishing a Cloud Broker Model, we explored the possibility of how IT services functions within organisations, and more specifically, how the information security function within an enterprise should look to pilot these cloud broker roles.
This is because the information security function is optimally placed to articulate compliance requirements and risk profiles—it has the best position for understanding the business process and information flow, whilst also ensuring the environment is secured with adequate internal and external cloud controls.
In Part 2 of Establishing a Cloud Broker Model, we introduced a 10-point process that supports “Service Strategy” for cloud brokerage based on Gartner’s Cloud Broker Model that includes Cloud Service Intermediation, Cloud Service Aggregation and Cloud Service Arbitrage function areas.
The more discussions I have and the more executives and practitioners I speak to, leads me to conclude that although my initial premise (information security leading the charge) is appropriate from an operational perspective—and linking it to the ITIL “Service Strategy” capability pillar is more appropriate—change within organisations is lead through teams or functions that undertake and influence design and implementation of these solutions, security or otherwise.
With this realisation I have revised my thinking. Most organisations today have an “Architecture” function that has a major role to play in how a business requirement is taken from inception to implementation. I’d now say, therefore, that Cloud Services Brokerage is the new enterprise architecture or the next evolution of enterprise architecture.
What is enterprise architecture?
Let’s try Gartner, executives love Gartner: “Enterprise architecture (EA) as a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analysing the execution of change toward desired business vision and outcomes.
"EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalise on relevant business disruptions. EA is used to steer decision-making toward the evolution of the future state architecture.”
Quite a mouthful, but really, it’s simply a function that helps executives make decisions on strategy and direction.
The Open Group Architecture Framework (TOGAF) says: “An architecture framework is a foundational structure, or set of structures, which can be used for developing a broad range of different architectures. It should describe a method for designing a target state of the enterprise in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.”
Again, an approach that meets the requirements of a target state of where the business needs to be, standard tools and compliant products are used as building blocks.
What enterprise architecture discussion would be complete if we didn’t use Zachman. Surprisingly from the man himself: “The Zachman Framework™ IS NOT a methodology for creating the implementation (an instantiation) of the object. The Framework IS the ontology for describing the enterprise. The Framework (ontology) is a STRUCTURE whereas a methodology is a PROCESS. A Structure is NOT a Process. A Structure establishes definition whereas a Process provides Transformation”.
Which sounds like a lot without really say anything. I’ll try and decipher it—an instantiation of an object means initiating a service. In this instance a cloud service and initiating could be “building, consuming, migrating”, all requiring business funding and diligence to be successful.
So where am I going with all of this? Really, I am simply exploring the idea that cloud brokerage is (in my view) the next evolution of enterprise architecture. By aligning Gartner’s Cloud Service Broker capability areas with generic EA business benefits, I have developed the following key stages:
Cloud Service Intermediation
• Ensuring efficient business operations through standardised lower business operation costs, an agile workforce and improving business productivity.
• Establishing an efficient IT operation that improves standardisation and interoperability with easier system and network management.
Cloud Service Aggregation
• Improving the organisations ability to address critical enterprise-wide issues like security and enables transformation.
• Supporting the business to achieve maximum return on investment in technology whilst reducing the complexity of existing environments.
Cloud Service Arbitrage
• Providing the business with the flexibility to build, buy, or out-source its desired technology outcomes whilst understanding the overall risk in new investments and their cost of ownership.
In my view establishing a Cloud Service Broker model is not a new capability, it’s just an evolved capability aligned with the core principles of enterprise architecture.
Hence I say “cloud brokerage the next evolution of enterprise architecture”.