A new Deloitte debate "Does Cloud Computing Make Enterprise Architecture Irrelevant?" starts by asking if companies can get rid of EA troubles:
The world of business technology is shifting to "almost enterprise" applications - a network of smaller, more agile applications that are often hosted remotely, as in cloud computing. With less reliance on massive, monolithic enterprise solutions, it’s tempting to think that the hard work of creating a sustainable enterprise architecture (EA) is also behind us. So, as many companies make the move to cloud computing, they anticipate leaving behind a lot of the headaches of EA. But is that how things will really play out in the real world?
The debate has a wealth of points and counter-points to this statement. The proponents of replacing EA with the cloud assert that:
We’re outsourcing our EA headaches. No more having to manage the underlying IT infrastructure, operating systems and software patches... Vendors will bring best-of-class standards and processes that we can adopt. No need to fix ours... Our move to cloud is about being agile and nimble. Enterprise architecture is the polar opposite of that. If we add a layer of EA onto the cloud, we’ll lose most of the benefits.
The counter-points here is that:
Even when you push jobs and processes into the cloud, none of it will be standalone. Enterprise architecture will still have to govern how everything works together and supports the business... No matter how great the tools are or where they’re housed, you still have to define and manage the relationships and dependencies between mission, processes, technologies and business initiatives.
Some of the Deloitte practitioners weighted on the debate. According to Scott Rosenberger, although moving some of the processes to the cloud will make some of the technical implementation issues easier,
... it doesn’t change the underlying reality that there has to be a strategy for putting together all the people, processes and tools that the cloud supports... That means IT isn’t off the hook at all when it comes to EA. If anything, this complicates things.
Omar Trujillo Segura supports Rosenberg by stating that EA still remains relevant:
No matter what tool you use, the core problem isn’t the technology. It's in defining the relationships between all the different components of their vision, from business processes to technology. And that’s where EA comes in.
And Florian Quarre sums it up by saying that:
... cloud solutions may have a big role to play in reducing costs... But these new solutions have to fit a clearly defined systems need that has been spelled out in an operational model. This is where EA comes in; because selecting any technology outside of a business-driven enterprise framework is risky business.
Reacting to this debate David Linthicum writes that he is disturbed that this question has been asked at all. In his opinion:
Cloud computing does not replace enterprise architecture. It does not provide "infinite scalability," it does not "cost pennies a day," you can't "get there in an hour" - it won't iron my shirts either. It's exciting technology that holds the promise of providing more effective, efficient, and elastic computing platforms, but we're taking this hype to silly levels these days, and my core concern is that the cloud may not be able to meet these overblown expectations.
New technologies are great and we are all eager to use them. But using technology just for the sake of technology does not make sense. Technology use should be driven not by its "coolness factor", but rather by business requirements and underlying enterprise architecture. Indeed, moving some enterprise applications to the cloud can make some infrastructure woes go away, but badly designed solutions won’t be improved by moving to the cloud.
/filters:no_upscale()/sponsorship/topic/5f2caa51-d66d-486f-834b-0ca9c22b9c26/CockroachLabsLogRSB-1678379078926.png)
/minibooks/architecture-2023/en/smallimage/logo-1685600892155.jpg){kind=logo}
/articles/architecture-modernization-domain-driven-discovery/en/smallimage/start-your-architecture-modernization-with-domain-driven-discovery-small-1683106490819.jpg)
/articles/agility-architecture/en/smallimage/logo-1682078942739.jpg){kind=logo}
/articles/architecture-trends-2023/en/smallimage/the-infoq-trends-report-1680611416202.jpeg)
/articles/effective-architecture-conversations/en/smallimage/have-effective-conversations-with-business-stakeholders-about-software-architecture-small-1677231728391.jpg)
/articles/architecture-skeptics-guide/en/smallimage/a-skeptics-guide-to-software-architecture-decisions-small-1672223516348.jpg)
/articles/api-design-review/en/smallimage/API-design-reviews-are-dead-long-live-API-design-reviews-small-1684310900854.jpg)
/articles/finops-systems-thinking-lens/en/smallimage/12-places-to-intervene-rethink-FinOps-using-a-systems-thinking-lens-small-1679995317220.jpg)
/articles/framework-architectural-decisions/en/smallimage/logo-1679060242842.jpg){kind=logo}
/articles/istio-ambient-mesh/en/smallimage/logo-1678364642232.jpg){kind=logo}
/articles/creating-decentralized-apps/en/smallimage/LOGO-1676916574942.jpg){kind=logo}
/presentations/data-streams-architecture/en/smallimage/Kai_Waehner-s-1675025271514.jpg)
/articles/infoq-software-trends-report-2022/en/smallimage/InfoQ-Trend-Report-logo-small-1672911593669.jpg){kind=logo}
/minibooks/2022-infoq-trends-reports/en/smallimage/LOGO-1672051527011.jpg){kind=logo}
/articles/architecture-architecting-role/en/smallimage/logo-1670404086277.jpg){kind=logo}
/articles/delivering-fast-testing-strategies/en/smallimage/deliver-fast-tests-have-to-last-small-1685548178496.jpg)
/articles/eda-mediator/en/smallimage/event-driven-architecture-with-mediator-topology-small-1685547200315.jpg)
/articles/azure-functions-quarkus/en/smallimage/azure-functions-on-quarkus-3-1685542580748.jpg)
/presentations/lyft-cd-benefits-challenges/en/smallimage/tom-wanielista-small-1685002834068.jpg)
/presentations/green-software-growth/en/smallimage/Marco-Valtas-small-1685609473905.jpg)
/articles/test-automation-ci-cd/en/smallimage/effective-test-automation-approaches-for-modern-CI-CD-pipelines-small-1685355310638.jpg)
Community comments
Is Enterprise Architecture Still Relevant for Cloud Computing?
by Niels Hilbrink,
What a load of bull
by Luis Espinal,
EA still matters but focus would be different
by Faisal Waris,
Traditional EA will change
by Nikita Ivanov,
Move to cloud allows better fit with business requirements
by Oliver Searle-Barnes,
Re: Move to cloud allows better fit with business requirements
by Tiberiu Fustos,
Is Enterprise Architecture Still Relevant for Cloud Computing?
by Niels Hilbrink,
Your message is awaiting moderation. Thank you for participating in the discussion.
Cloud Computing is a technology concept with many implementations, very few of them interchangeable. Enterprise Architecture is a function that allows a company to build a foundation against which to execute their business strategies ... I fail to see how these are related.
If the question is whether or not core IT services will be provided from the cloud rather than corporate datacentres then I guess the answer is: yes! as any new technology will find a place to live in a enterprise services sooner or later. Whether this will be in the form or private, semi-private or public clouds, IAAS, PAAS or SAAS depends on corporate IT policies, user requirements, and application constraint.
As for Enterprise Architecture, this is a function that provides governance over technology design and operations for the infrastructure needed to execute the various business processes, it was needed in the past and will be needed in the future in order to make sense of the myriad of technologies that are blasted at todays enterprises each day.
What a load of bull
by Luis Espinal,
Your message is awaiting moderation. Thank you for participating in the discussion.
Quoting from the article:
Anyone who thinks there will be no infrastructure pains, nor patches in the cloud needs to stop drinking the kool aid. Believing such crap is a symptom of a a gross misunderstanding of what the cloud is. Businesses are going to run cloud services at different levels of integration: from bare-metal slices where we start from scratch up (think RackSpace) to highly integrated, language-specific slices (think Heroku.)
And just like anything, patches have to take place. Whether they are done by us (if owning bare slices) or by the provider (.ie. Heroku), patches and changes will take place. Down times, scheduling, regression testing of applications, etc. All those pains will still remain regardless of whether responsibility for upgrades remain with us or cloud providers.
And that's just a fraction of the pains of IT architecture, which is not the same as EA.
What sort of illiterate snake oil salesman could possibly make an statement like that???? How can they possibly substantiate such statements while keeping a straight face? Snake oil and silver bullets, the plague of the software industry.
Riiiight.
More snake oil. Somehow people seem to think that using nouns like "agile" and "nimble" is enough to make a valid argument. It is not. Moving to a cloud paradigm is based on a variety of enterprise-specific motivations. Agility is only of them, and only for a certain class of businesses.
Apples and oranges. This seems reminiscent of today's politics where name-calling trumps all. Saying that EA is the polar opposite of agility does not make it so. Anyone who says so doesn't have a full understanding of EA or agility.
Speculation. Seriously, it hurts the brain to contemplate such asinine questions.
EA still matters but focus would be different
by Faisal Waris,
Your message is awaiting moderation. Thank you for participating in the discussion.
There are really two views of EA - a) a business function to align technology with strategy and b) a more prosaic IT function of governance/guidance to optimize IT investment and processes.
Since (a) does not exist (as far as I know), lets assume (b).
The decision whether/how much to use public/private clouds is an EA decision so from that perspective EA matters.
The focus will have to shift from infrastructure architecture to application architecture. Applications will have to be architected differently to take advantage of cloud environments.
This is a key point. A programming model shift (if not a paradigm shift) will happen. EA has to guide the enterprise through this transition.
(Namely, ditch Java in favor of Scala - just joking!)
Given the emergence of the Azure 'appliance' by Microsoft, private and public clouds may end up looking the same over time making this shift in application architecture even more pronounced.
Traditional EA will change
by Nikita Ivanov,
Your message is awaiting moderation. Thank you for participating in the discussion.
In a traditional meaning of EA - it must change. Cloud infrastructures are dramatically different on how they affect the way we build enterprise systems - if one wants to take the full advantage of cloud infrastructure (and not just merely running the same stack on VMware at someone's datacenter).
Most, if not all, business systems built in the last decade cannot take advantage of the elasticity that clouds provide. All our Tomcats, Spring, JBoss, Weblogics essentially are square pegs for the rounds holes when it comes to elasticity.
Nikita Ivanov.
GridGain = Compute + Data + Cloud
Move to cloud allows better fit with business requirements
by Oliver Searle-Barnes,
Your message is awaiting moderation. Thank you for participating in the discussion.
It never should have been a central IT body making decisions about relationships, processes and tools. Having a central strategy for putting people, processes and tools together was necessary to provide cost effective IT. With the cloud and metered/subscription billing it's now possible to choose cost effective tools for individual business cases. The IT teams that work alongside their respective business unit are far better placed to make decisions regarding technical needs, they can respond far faster and with greater accuracy.
Re: Move to cloud allows better fit with business requirements
by Tiberiu Fustos,
Your message is awaiting moderation. Thank you for participating in the discussion.
This is a very interesting point that I started thinking about more and more. It's not directly related to cloud, only that cloud enhances the available tools.
We have this already a situation where business units bringing products to the market built entire "production" and "operation" IT tools directly with probably the most agile tool availabe to the business: Excel.
We spent the last 3 years trying to "break the silos" - data redundancy, quality etc. is acceptable up to a certain point and then comes a tipping point when this simply does not work anymore (think about bundling all these products developed in business silos).
Now I tend to think that the fine-tuned solution is somewhere in the middle: silos (supported by cloud-based tools developed by business teams supported closely by dedicated IT) are still allowed, but focus the governance for those managed set of common capabilties that ensure efficiencies for the overall picture.
IT costs are not necessarily the biggest issue - sometimes the process costs of allowing the silos exceed them :-)
Interesting topic...