Enterprise Architect or Enterprising Architect: Will the Cloud disrupt traditional paradigms of EA? (Part 1.)

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.


I don't think it will disrupt traditional paradigms of EA but will of IT. My perception is to have a successful EA you do not need any IT. Yes, this is an extreme but I think about the rebuilding of Haiti. IT could be very light but a good EA is needed. EA is designed to go through cycles, all that would happen is that the IT component would be modified to be delivered in the cloud rather than on premise on the next round. A good EA would not have 'business bypassing IT' and a good EA would not just be for IT but include business. If it is not enterprised focus, then it's simply an IT Architecture.

Posted by Paul Naish on March 02, 2010 at 08:10 AM EST #

I am in general agreement with Paul. EA is necessary regardless of changes to underlying technologies. Done properly, EA will iterate and adjust to the winds of change. Cloud, SOA, Client/server, RFID and other technology fads ("innovations?" "revolutions?") may throw solution architects for a loop, but EA is at the heart of change. We have the responsibilities to: - Investigate hype - Understand benefits and risks - Communicate to both business and IT - Establish governance - Align with business requirements - Give guidance for sustainable innovation If EA doesn’t take on cloud computing, it will result in exactly what you suggested: spaghetti clouds.

Posted by Brad Goodwin on March 04, 2010 at 06:11 AM EST #

I do see the author's point here. The VP of IT Governance needs to constantly communicate with all levels of every unit to see if this type of stuff goes on. I have been on the giving and receiving side of this issue. As far as cloud technologies are concerned, If anything cloud technologies will make our lives easier. As an EA support and capacity planning also come into play as requirements of the application life cycle. Cloud technologies will now allow us to facilitate this process through the vendors. EA's don't care if we have a cool data center. We just care if the application or technology does what is supposed to do. The EA's main goal is to execute the business strategy via technology not purchase new cool technologies for technology sake.

Posted by Anthony Giannino on March 08, 2010 at 02:59 AM EST #

Will the Cloud disrupt traditional paradigms of EA? To bring it closer to home, wouldn't the question be the same as asking: 1. Will it make any difference if I put my entire Home PC into the Google space? 2. And will it shift the "bread & butter" (home) or "brick & mortar" (business) paradigms?

Posted by Van Luu on March 08, 2010 at 09:52 AM EST #

Great article - I think that because of the Cloud shift, if we are left with no IT or little IT, then there will be no EA or little EA.. That's not thinking out of the box - that's just logical.

Posted by guest on March 08, 2010 at 10:37 AM EST #

First, when it truly comes to aligning technology with business strategy, I'm with the group that says there is little impact on EA. The technology implementation is only relevant EA in as much as it delivers (or not) the capabilities that the future state calls for. That said, what we really need to be talking about is where EA can help to make the shift to cloud computing smooth. I can highlight a similar shifts in my career, where the balls were dropped and how EA can help to avoid them. Please consider this metaphorical because I am about to jump deep into the weeds. Extrapolate please... Here's a simple example from the SOA world. How many companies migrated existing functions (think method on a class) to a service interface, setup simple orchestrations, only to find they totally lost transactional integrity? This is because virtual machines like Java or .Net handled much of the integrity within the VM, they were used to that and assumed it would be there. On to SOA version 2.0 at that company… The point regarding cloud computing is that as companies select these new options, they're highly likely to make assumptions that just are not true. So now I will go way back up the stack... The company has a robust view of all customer interactions across all channels because those EAs did a bang-up job. They buy the option to host their new customer-related app at MyBigCloud.com. A few months later, their customer interaction numbers are dropping which doesn't match their sales figures. Why? Because the contract for their cloud solution didn't include a fed of customer interaction information back to the mother ship. I good EA practice will have identified ALL the key points of business integration for the effort and ensured that this did not happen. Data integration in particular will be a big issue with cloud computing because it pushes information back into siloes, siloes which IT may not have direct access to the data stores. It's my opinion that for technical EA shops, sure cloud computing could be a big hit, but for a business that want to successful adopt cloud computing in a way that aligns to their business strategy, EA will be absolutely integral.

Posted by Carl Kessler on March 31, 2010 at 03:33 AM EDT #

At Business Technology Summit 2010, to be held 11-12 November 2010 in Bangalore, Dr. Chris Harding will speak about Using Cloud in Your Enterprise Architecture, Managing Cloud Risks, SOA for Interoperability, and SOA Governance. The summit also features topics like Soa, SaaS, PaaS, Cloud Computing Governance and many more.

Posted by Swagat Barman on October 24, 2010 at 08:45 PM EDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Art, Artifacts, and Best Practices for Enterprise Architects


« July 2016