Refactoring Enterprise Architecture

For the past 10+ years, I have struggled with concept called Enterprise Architecture. I began as a programmer delivering not really great systems, but they were usable and delivered pretty fast. After I finished my computer science education, for many years fulfilled software architect positions and last 7+ years I was often called enterprise architect, although I don’t like the term at all.

Well, I learned so much B.S. about enterprise architecture, that I eventually started searching for a completely new ways of dealing with the question like “Why do we need enterprise architecture?”. I didn’t find the answer in explanations from others. Maybe only bits of it. Scattered all over the internet and books.

Many years ago I have embraced Agile Manifesto as a really great improvement in our profession. The only problem is, the are still no real answers how to deal with IT architecture and related questions.

Scott W. Ambler is probably the most known figure in the combination of Agile and Enterprise Architecture, but his article about Enterprise Architecture starts like this:

When project teams work under the assumption that they can do anything that they want, that they can use any technology that they want, chaos typically results.  Functionality and information will be duplicated and reuse will occur sporadically if at all.  Systems will not integrate well…

I don’t know about you, but I find this nonsense. Even disrespectful towards guys and girls who actually build the systems.
So, based on Agile values I’ve started for number of years defining and applying my own way of dealing with IT architecture on project, programme and enterprise level.

This can be compiled into following principles. The correct formulation is still work in progress, so I welcome any feedback:

  1. Teams committed to deliver parts of the enterprise landscape should also be responsible for the overall enterprise level architectural needs.
  2. Any architectural framework, methodology or best practice is a potential waste unless proven otherwise by directly contributing in delivery of business value.
  3. Enterprise architecture is defined just-in-time and emerges in the landscape driven by current business needs. At the same time directed by long term vision.
  4. Simplification of an enterprise architecture should be about the removal of unnecesary IT components instead of making nice looking drawings which usually oversimplify the real life complexity.
  5. The best enterprise architecture is also most refactored one.

So, this is my first blog about dealing with enterprise architecture questions the agile way.

4 thoughts on “Refactoring Enterprise Architecture

  1. Nice post Viktor! I think your principles formulate a very healthy approach to enterprise architecture. Start off small, trust your co-workers and keep an open culture. Be ambitious for results, instead of job titles and allow for implicit structures to emerge…

  2. Short answer would be: It's the same thing, only different scale.Longer answer: This implies that we do not need the notion of enterprise architecture as something special. For most enterprise architects this sounds ridiculous. One of the main reasons why I started this blog is to give answers on typical questions enterprise architects and others have on this subject, instead of simply stating: There is just architecting as a discipline and no such thing as agile enterprise architecture.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s