00
Enterprise Architecture is all about tapping synergies
across the enterprise – in a structured and consistent manner. Goes without
saying that different forms and flavors of EA exist dependent upon the starting
point, organizational culture or operating model. Forrester characterizes EA
based on the dimensions of orientation (Business or Technology) and focus
(Project or Strategy) [see: Characterizing EA Teams and their challenges.] But there is one thing in common
across all types of EA, and that is – having a shared enterprise-wide
understanding of what needs to be done for the larger good of the company – and
have different parts of the enterprise converge towards that vision and architecture.
And the mechanisms EA has traditionally used to drive
consistency and shared values are -
reference architectures, standards (for products, tools, canonical
models etc.), architecture principles and so on, which are adhered to by the
implementation projects and enforced at multiple levels using governance
processes and gating techniques.
So why is the Cloud paradigm such a big deal? Well for
starters, it threatens the whole premise of IT sourcing and decision making – where
businesses, at least theoretically, can now bypass corporate IT shops
completely to source their applications, infrastructure and platforms from
external providers – in a cost-effective on-demand basis.
On a less dramatic level, it shifts the focus from choosing
and deciding about products or architectures to instead being concerned about
services – regardless of the underlying products or tools enabling the services
- and without having to worry about managing or maintaining those services
(unlike in the case of say SOA). But it doesn’t stop there – it also introduces
interesting twists to key EA processes.
For example, zooming in on one process – the classic Software
Development Life Cycle (SDLC), some of the nuances that could get introduced at
various stages of the process with the Cloud option are:
-
Genesis: Traditionally, the EA team would
collaborate with the business to understand and scope the needs – and align it
with the enterprise architecture (bringing to bear the existing technological
capabilities that can satisfy those needs thereby promoting sharing or reuse or
building new ones if needed). However, given its relatively low barrier to entry, in the
scenarios where the Business is not sure of the viability of their proposal,
they can go straight to the Cloud instead to “experiment a bit” before solidifying
their requirements – which could be a path of no return..
-
Approval: Instead of now having to provide
standardized ROI or cost-benefit analysis justifying the products that need to
be bought or charge-backs that need to be agreed upon upfront for shared assets,
the Business can provide operational expenditure outlines and go out to the
Cloud to source their requirements. No CapEx sticker shock, no new product
introduction training line item expenditures, no gnarly charge-back agreements
between Business Units – in short, no need to conform to existing
enterprise-wide Reference Architectures to meet individual project needs.
-
Development & Deployment: The development and
deployment teams would now be sourcing from and conforming to the Cloud API and
services – without the EA team becoming a cop enforcing the reference
architectures or corporate standards at various checkpoints. With overarching cross-project
oversight not relevant anymore, each project would tend to work in its own Cloud
development sandbox – party engendered by the partitioning paradigm of the
Cloud itself..
-
Operations & Maintenance: Barring some
exceptions, traditionally the EA teams have not been hugely relevant to the Ops
side of the house – but with the Cloud, even that seems to be waning. The Cloud
providers will furnish the relevant tools for management and reporting – and take
away the onerous tasks of patch management version upgrades, HA/DR and the
like. What value will the EA add here?
Given that the entire notion of enterprise architecture is
based on the premise that the whole is greater than the sum of its parts, and
that there are far greater cost or agility or innovation options when the
architecture is optimized for the enterprise as opposed to optimized for a
point solution or a business segment, it appears that the Cloud paradigm is
paradoxical to enterprise architecture.
With each Business Unit inexorably being pulled to its own
“point” Cloud, will EA go from dealing with Business silos to managing Cloud
silos? Or is the Cloud going to marginalize Enterprise Architecture? How can
the traditional EA become more enterprising to embrace the Cloud and evolve
it’s processes and models to prevent fragmentation and segregations of Cloud
sourcing solutions?
Would like to hear
your thoughts and explore the options in the next posts.
