How Enterprise Architecture enables Web 2.0

The role of an enterprise architect is not well understood.  That much is clear.  Some folks say that EA is at one end of the scale, while Web 2.0 is at the other.  Those people are not enterprise architects.  They are missing the point.

Web 2.0 is about building solutions in a new way.  Enterprise Architecture does not tell you to build the solution in the correct way, as much as it tells you to build the correct solution. 

Enterprise Architecture would be completely unnecessary if you could simply teach all of the practitioners of IT software development to build the right systems.  In fact, that was the first approach most organizations used. 

Smart people would notice that stupid things were happening, like many systems showing up in an organization, all doing the same things in a different way, each consuming millions in cash to create and maintain, instead of building smaller components, with independent capabilities, hooked together with messages.  Smart people would say "This is dumb." 

Management would say "We agree.  Tell everyone to stop doing that."

Smart people would tell other IT staff to stop doing it.

And it kept happening.

So Enterprise Architecture is born.  Not to be a bastion of smart people who are somehow smarter than anyone else.  Nope.  To be a group of smart people who are incented differently.

Every day, I make decisions.  Some of them are easy.  Others are about as difficult as they come.  I have a set of principles on my wall that I use to guide my decisions.  They are public principles.  Others helped to craft them.  But I don't report to those others.  I report to central IT.  So when the customer says "I need to solve this problem," and IT says "Let's build a glorious new infrastructure," I can say "No" without fear of reprisal.

And here's the kicker:

I can say "I've been working with this other team, and they built a bunch of apps based on shared services.  Those services do the same things that you need done.  The services catalog is at https://servicecatalog and I expect you to use those services.  Take a look.  I will review your design doc.  If you aren't consuming those services, you will stop.  If you are adding to the list, I'll be thrilled."

Then I sit back, and watch the "next generation web" launch itself into success.

Look, there are going to be a lot of things needed to make the next web successful.  I've blogged about them in the past.  We need to know which services to pick, and when to pick them, this is true.  But we also need to know when they have died, and which dependencies a service has, so that we can adapt to changing situations. 

As an Enterprise Architect, I am incented to think about these things, find solutions, and make sure we are all using them.  That way, when you pick a service, you KNOW how reliable it is (because it uses our framework which allows you to inspect the uptime numbers), and you KNOW that it can handle the traffic you are going to send it (because we required that the team that developed it performed a scalability test and published the results for you to see). 

For those services that have no information, you can use them... I won't stop you... but your customers (the business users who are paying your salary), they will.  They like cheap.  They like agile.  They don't care how.  But they do care that it runs reliably.  They do care that it can be tested. 

Enterprise Architecture is not the Central Soviet of IT.  We are the city planners who set zoning, inspect new construction, enforce setbacks, and protect wetlands.  You are just as free to make a brave new world of Web 2.0 with EA in the picture. 

In fact, you are far more likely to succeed if we are there.

Comments

• Anonymous
  April 23, 2006
  This really resonated with me.  As the enterprise architect, I've been asked by the CIO to take responsibility for making sure IT does the right things the right way (i.e. governance) and let the app dev and ops directors worry about getting things done.  That makes sense, but therein lies the challenge, since neither ops nor dev groups share all of the same values as me. So while I can get the architects to do the right things the right way and put enteprise concerns before project or operational concerns, it's still a challenge to get the ops and dev community to value that as well. Even if they "get it", they still end up valuing what their bosses value. The job of the architect is now to get everyone to value the same things to the extent possible through outreach, example, and carrot/stick.