Stop talking about enterprise architecture. Go solve a problem.

Many years ago, as a newly minted lead architect, I had a memorable initial 1×1 with our organization’s CIO. After reviewing my hand drawn (pencil on paper) application and information landscape, and hearing the CIO’s vision for common front-ends across retail, catalog and (burgeoning) web channel, we discussed the state of the union, and the inevitable gap from here to there.

After I listed ten or so gap items, I looked to the CIO for verification and prioritization. Instead, the CIO said, “I don’t care what you do, just do something.”

I admit. I was taken aback by the CIO’s response. Afterwards, I sat in my cube wondering why the organization created this new (enterprise architecture predecessor) position, if the big boss didn’t care what I worked on.

Then though, thankfully, I interpreted the CIO’s message differently, correctly. The CIO didn’t care which of the litany of items I picked, because tackling any item would move us closer to the ultimate, customer-centric vision.

This is the perspective I draw from as I advise architects and enterprise architecture groups who struggle in starting, or revitalizing an architecture practice. To get traction, don’t get tangled up in a framework or methodology, go solve a problem.

The problem doesn’t even need to reside in the (traditional) enterprise architecture domain. Nor does the solution have to be perfect, or in classic form. Just move your organization closer to there, from here. Repeat as required.

While this problem-solving, action-oriented approach can slow-down the generation of traditional artifacts and processes, it does accelerate value generation, and really, isn’t that the point.

Need to grow your architecture practice and credibility? Go solve a problem.

PrintFriendly and PDF

Comments

  1. Adrian Grigoriu says

    An enterprise architect that looks for problem any problem to solve is not an EA architect or is looking for a new job. In any case he is not happy with his job.
    As an EA architect, you solve problems by doing your own job that is by offering people the EA they need to address their own concerns in the wider context of the enterprise.

    The EA provides the blueprint which is the context where the stakeholders’ parts fit in, the principles, guidelines, roadmaps and strategies that help the others do their jobs better.

    Probably your CIO was fed up with the EA just talking and tripping everybody around.

    • brenda michelson says

      Adrian – thanks for commenting. What you describe sounds like a mature, well-received, value-add enterprise architecture practice. That’s terrific.

      The purpose of my story, my industry experience, is to share there are many ways to get there. The path taken depends more on business/organizational context than traditional, formal, enterprise architecture methodologies and guidance.

      And for clarity — this came up on twitter as well — the problems I advocate solving aren’t just any problem, but problems that impede a strategic path or goal.

      That was the list I presented to my CIO, which we then undertook, over time, while building out the enterprise architecture and supporting practice.

  2. says

    I love this Brenda. Had a very similar experience just a few weeks ago. After the head of the proposed EA CoE finished briefing his CIO (with us in the room for support), the CIO turned to us and asked “Will his plan actually produce something tangible or is he just full of shit?”

    • brenda michelson says

      Perfect! Every EA type everywhere needs to be asked this (or similar) question, and more importantly, know it will be asked, and therefore have a strong, action-oriented answer.

  3. says

    I was recently advising a start-up which had excellent founders and based on a great idea. Their problem was that – since they were intellectual people with wisdom – they were tempted to learn from the mistakes of the others.

    Normally there is nothing wrong with that right? But in this case, it was just a bit too much.

    They were spending most of their time and energy reading stories in TC, browsing the net for the possible problems they will face. Heck they were already well equipped with rounds of financing even before having the product-market fit.

    They needed to be told: OK,guys, we need to stop this madness. Let’s execute and we will see what happens. But for god’s sake, let’s go. Do something.

    I felt similar sentiments here while reading your excellent post. While I can agree that it is not about “solving a problem” literally, it has to be about “doing”. Even the Technical Architects have a great risk of being in the Ivory tower, Enterprise Architects have much more risk in having less percieved practical value. We need to have roadmaps converted into projects and chase them to get started.

    • brenda michelson says

      Sidar, thanks for sharing. Exactly: Do something. In a time-box, with checks/tests for plausibility and value, resulting in continuation or rethink.

  4. Adrian Grigoriu says

    Right, there may be “many ways way to get there…” as you say but still, the EA architect is not the problem solver, the trouble shooter of the enterprise, not even of the IT.

    Paraphrasing the proverb “give a man a fish and you feed him for a day, teach a man to fish and you feed him for a lifetime”, the EA architect, rather than solving the stakeholders’ problems (for that there are solution architects and domain experts), should provide the blueprint, principles, guidelines, process checkpoints and strategies that the stakeholders should employ to achieve their goals, in alignment.

    True, in practice, it often happens that instead of delivering to expectations the EA architect does all kind of odd jobs to justify the pay. That happens mainly because most EA frameworks today help little the EA architect little with modelling the enterprise. Typically, the frameworks describe the development process, project management best practices and at best, list a few artefacts…

    The problem is that the EA architects have to model the enterprise rather than invent yet another EA framework.

    Perhaps the CIOs’ attitude may be explained by the fact that they would rather see the EA architects do some work rather than policing the work of the rest and promising around benefits that never materialise.

  5. says

    Right on! Enterprise Architecture needs to be a problem-solver first, then a methodologist. Unfortunately, it’s said if you want to stop work for the rest of the day, ask EAs to define Enterprise Architecture. We have to stop being so obsessive about our precious methodologies and pretty pictures. When the organization throws a problem our way, the right answer is not a picture or a model, it’s a solution to the problem informed by senior knowledge and experience. By problem-solving, I of course don’t mean tech support or doing everyone else’s job. I mean developing strategy, supporting a PM in launching an EA project, or suffering a little to create a really insightful roadmap.

  6. Santhosh says

    Thanks for this post. I was starting to take up a similar stand lately after all the attempted ‘big picture’ stuff that I did/seen others doing landed nowhere.

  7. says

    I call this approach Stealth EA – focus on the solution, don’t rant about the framework. We just get the job done and the framework and techniques that we develop and apply allow us to enable the business to be more successful. Tough to do sometimes though – lots of academic EA out there.

Trackbacks

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>