Why Enterprise Architecture Will Vanish From This Earth

Although your world wonders me,
With your majestic and superior cackling hen
Your people I do not understand,
So to you I shall put an end
And you'll
Never hear
Surf music again

"Third Stone From the Sun"  -- Jimi Hendrix

Here is a bold prediction:  Enterprise Architecture as we know it will cease to exist by 2020.

Why do I think this?

It’s because enterprise IT (which includes architecture) has failed utterly and is rapidly becoming obsolete.  It will either morph into a form that is almost indistinguishable from today’s IT or it will also cease to exist. 

Allow me to explain.

Enterprise IT as a function came into existence when computers were expensive and rare.  We were entrusted with safeguarding the company’s data and managing the company’s extremely expensive investments in IT.  My first job out of college was working in an IT R&D group.  Our primary responsibility was testing new hardware and software to see if it worked as advertised and then selecting corporate standards.  We literally published a catalog of things you were allowed to buy.  These days, the idea of BYO has led to more and more personal technology in corporate America and the cloud has led to "shadow IT."  All of these trends reduce the importance and the authority that corporate IT once had.

I wrote about this in my first book , and the trends and failures that I predicted there are sadly coming true.  Traditional IT organizations are facing more and more pressure to change or to simply get out of the way.  In that book, I suggested an alternate model of IT that I called the “Customer Centric IT” model.  To summarize, it looks like this:

Traditional IT	Customer Centric IT
Sets IT Standards	Supports Business Requirements
Focus on Operations Excellence	Focus on Customer Satisfaction
Engineering is key skillset	Consulting is key skillset
Sets Policy	Seeks Input
Focus on Large Projects	Focus on Smaller Projects
Organized by Technology	Organized by Customer
Technology Focus	Business Value Focus
Delivers most projects in house	Brokers external vendors as needed

Similarly, if we think about the traditional Enterprise Architecture team, they are very focused on traditional IT values like “setting standards” and “setting policy.”  If there is one thing we have learned about cloud and the new way of building applications it’s that the development team is the one team in your organization that is qualified to make decisions about the tools they use and the architectural elements they need to succeed.  This fundamental democratization of developer tools has started a revolution in IT that is only gaining ground.

Thus, the entire concept of what the architect’s role is has changed and is continuing to change.

Software Eats the World

As Mary Meeker points out in her excellent state of the internet report last year, there are major sectors of the US economy which are being or are about to be disrupted by software.  Specifically, the top three areas of consumer spending, Housing, Transportation and Food (65% of US consumer spending in total) are all facing disruption due to software based competitors.  The implication is that the pace of innovation and the business model of software is coming to many more industries than in the past.  Realistically, this means that most companies are going to need to treat software as a key piece of their value proposition in order to survive in the modern digital world.

While this trend is not new, it is continuing to accelerate as internet adoption rates in the United States approach those of radio and TV.  Smartphones, the cloud and other technologies have made software more ubiquitous than ever and more industries are starting to react to this new threat.

As the interface between business and technology, this is a huge area of concern for architects.  If you don’t have a plan for dealing with software disruption to your business, you’re probably not doing your job as an enterprise architect.  Traditional, legacy, IT policies are designed to promote cost effective, stable platforms that protect an enterprise business from technology’s foibles.  However, this policy no longer works.  If your goal is to compete with a software company, you need to operate at the speed of a software company.  Once technology becomes a revenue source, things like velocity and agility become the most important considerations; more important than ROI or stability.

When you optimize for velocity, things like standards, cost controls and other traditional IT functions cease to exist.  Individual teams can make decisions faster than enterprise wide architecture review boards.  Interoperability and standardization are only important when it comes to cross feature dependencies.  Inside the individual system, getting your features out is the most important thing.  This lessens the role of the central architecture group. 

While some claim this makes enterprise architecture irrelevant, I disagree.  What it does is shine a bright light on what the hell enterprise architecture is supposed to be for.  In reality, the enterprise architecture team has a very limited role.  Our role is to ensure that the minimum viable governance models are in place to ensure that vital regulatory, security and other policies are enforced.  In the end, the tools your developers use isn’t really important.  But if you fail your SOX audit, there will be hell to pay.  The exact amount of governance you need will vary by industry but you should always be focused on how to achieve the absolute minimum.

Thus, the question for enterprise architects is this:  How do you reduce your role to the absolute minimum?

This may seem counter-intuitive but scaling back your role to the bare minimum may be the only way to save enterprise architecture as a function in your organization.