Day to Day Enterprise Architecture
I had a great conversation with an old friend about the day to day efforts of Enterprise Architects. I had to admit, since he was thinking of hiring an EA in the coming year or so, that most of the material for EA is really poor for preparing an EA for their day to day job.
Honestly, if you look at TOGAF or some of the smaller frameworks or even approaches, most do a lousy job of telling a new architect "Here's what you should be doing today," or even providing a mechanism to step back and say "what's missing that I need to address?"
To me, EA is only really an interesting job if we produce useful outcomes. Not useful artifacts. Not pretty frameworks. Not perfectly aligned definitions in a hierarchy that EA alone cares about. Useful outcomes.
In other words, the business gets a useful benefit for having employed the EA.
Typically we describe an ideal outcome as "things get simpler" or "processes are easier to change" or even "the systems of the company are more efficient." This quickly turns into a discussion of measures.
These are not the only measures that should be considered... not by a long shot... but they are the typical starting place especially for companies that don't have an EA program and largely have never figured out how to justify the cost of a full time Enterprise Architect.
领英推荐
But even if you can agree on how to measure EA, can you describe a method that says "start here?"
It occurs to me that I can. And I have. Many times. In fact, the basic elements are something that I published in public, on my blog and even here on LinkedIn over 15 years ago. But while I created a frame of reference, I never told folks how to use it. And that's on me.
I've matured up a good bit, to be fair, both as an EA professional and as a person. So I'm not sure that anything I would have described back then would be a reasonable method I'd share today. But it's time.
So, in conjunction with some of my EA friends, I'll start describing some of the ways that an EA can approach their work to produce something that has a useful outcome, a measurable impact, that business stakeholders will understand and appreciate.
It's not impossible. I've done it. Many times. I just need to figure out how to put into words a method that is useful. I've checked my ego at the door. I'm open to challenge and improvement... it's time to share.
President and Chief Data Officer at Logical Data Guy Consultants
1 年Nick Malik With respect to your friend who was "thinking of hiring an EA in the coming year or so". Why was your friend thinking of hiring an EA? What did your friend think and EA was going to do? What problems did your friend expect the EA to address? Once those questions are answered, it's pretty easy to figure out what the EA is gonna do on a day to day basis.
Senior Enteprise Architect & Cloud
1 年Excellent reflection, I totally agree with your concerns.. The mindset should be Outcomes oriented, definitely, as part of that mindset is really important to know the Use Cases where Enterprise Architecture can add value, is not only about artifacts, frameworks, standards, conceptual things, etc, but also when we know very well the Use Case, like Application Rationalization, Migration to the cloud or Modernization, Merger Acquisition.. Instead of to know the general TOGAF ADM process, is good approach to have the step by step about How to figure out a specific Use Case, in that way is easier to showcase the EA Value.
Nick, I too have wondered how best to articulate the value proposition of EA. Not just for new architects, but also for existing architects and senior leaders. I often start my attempts with the disclaimer that "nobody cares about EA except Enterprise Architects". That helps bring the focus back to value and what EA can contribute. Unfortunately the value an EA can bring to an organization varies very much by the type of organization and the situation the organization is in. I've often thought that what we need is an EA pattern book that provides a bunch of stock choices that we can all talk about and use as a frame of reference.
Distinguished Architect | Technology Leader | ex-MSFT
2 年It is not just about outputs, it’s about outputs that are framed the right way for each stakeholder and formatted in a way they can consume AND use to make decisions