The State of Enterprise Architecture

Recently there was a panel discussion regarding “The State of Enterprise Architecture: Vast Promise or Lost Opportunity?“. It was actually a very interesting panel discussion. Take a peek when you have a moment.

Here are a few excerpts that I really agree with:

In a lot of cases, we make a big deal about the technical expertise of architects, but in a lot of architectural engagements that I have been involved in, I didn’t actually know anything at all about the subject matter that I was being asked to architect.

What I did know how to do was ask the right questions, find the people who knew the answers to those, and help the people who actually had the information orchestrate, arrange, and understand it in a way that allowed them to solve the problem that they really had.

This is very true. It is all about asking the right people the right questions and even more often it’s about asking those same people the next two or three questions that are the real answers you are looking for. This also isn’t something that is easy for anyone to pick up. While the occasional cheat sheet/checklist is good as a refresher to make sure you tied everything off it should be used as the end all be all. Questions alone with out the right people asking them are not effective.

In terms of its maturity as a profession, it may be 100 or 200 years back, compared to law or medicine, but on the other hand, the quality of the practice is much more like where medicine and law were 50 year, 25 years ago.

I have to agree on a lot of fronts. It is somewhat the EA Wild West out here. There are so many competing frameworks, certifications and methods that it is difficult for the EA community to have a common vocabulary or measurement.

The fundamental with leadership in EA is that architects don’t own things. They are not responsible for the business processes. They are not responsible for the sales results. They are responsible for leading a group of people to that transformation, to that happy place, or to the end-state that you’re trying to achieve.

Enterprise Architects only have influence to the organization where it needs to be. This is both good and bad. I think that the previous comment made about the quality of the EA practice being equivalent to 25 to 50 years ago wouldn’t be the case if EA’s didn’t have to “earn there keep” as influencers. They have to earn there stripes to be effective in the industry. This is the true test of a good EA.

If you do not lead and do not take the risk to lead, the transformation won’t occur.

As an EA it’s all about putting yourself out there and taking calculated risks for yourself, not necessarily for the company.

Again, very good panel with Dana Gardner,Jeanne Ross, Dave Hornford and Len Fehskens.

For more information and the full article:

[UPDATE]

Direct link to audio podcast: https://www.opengroup.org/events/podcasts/BriefingsDirect-State%20of%20Enterprise%20Architecture%20With%20The%20Open%20Group.mp3 

Advertisements

0 thoughts on “The State of Enterprise Architecture”

  1. The first excerpt, asking the right questions, certainly seems a good thing. I just wonder if it really is an architecture thing. Wouldn’t someone with business savvy and good communication skills be able to achieve exactly the same results?
    I am just wondering. As soon as people start defining enterprise architecture, it seems there just is no subject that it does not touch. I have heard enterprise architects comprising finance, strategy, resource management within their scope. The necessary skills (verbal communication, written communication, people sensitivity, organization sensitivity, historic sensitivity, to name a few) always include the entire catalog.
    Would it be possible to define enterprise architecture by what it is not?

    Like

  2. Hi Marc,
    First, thank you for your thoughtful response.
    Yes, I agree that the first bullet is an interesting one. I do think that this is the role of an Enterprise Architect. They should have the qualities you pointed out such as business savvy and good communication skills.
    As far as definition of EA there are quite a lot of definitions out there.
    Wikipedia (http://en.wikipedia.org/wiki/Enterprise_architecture)
    Enterprise Architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model. Practitioners are called enterprise architects.
    Gartner (www.gartner.com)
    Enterprise architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution. The scope of the enterprise architecture includes the people, processes, information and technology of the enterprise, and their relationships to one another and to the external environment. Enterprise architects compose holistic solutions that address the business challenges of the enterprise and support the governance needed to implement them.
    I’ve got another definition I use but will save it for another post…
    With both of these fairly mainstream EA definitions business savvy and communication are core. So I think you are most definitely thinking on the right lines.
    I see that there are a couple of challenges here:
    1. Architecture Soft Skills – The first quote has a lot to do with an architects listening and problem solving skills. You would be surprised to know that this is still an area that architects struggle with. Through working side-by-side with other architects of many varieties and interviewing architects I still see many of these architects on the market with the challenge of knowing the right questions, ways to ask, and drill into getting the right answer.
    2. EA isn’t Mature – Unlike most industries EA is fairly new even in the IT world. The reason EA’s need to ask so many questions is that there are not widely adopted frameworks to work within to ensure everyone is on the same page.
    3. Frameworks and Methods – While there are frameworks and methods many of these overlap or even conflict. There is a steep learning curve for architects and their customers thus there is a need to fully qualify problem statements and vision through thoughtful questions.

    Like

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