Enterprise Architecture Q&A

Puzzled

On May 17 2016 I gave a webinar entitled Agile Enterprise Architecture: Disciplined and Pragmatic Strategies (at this link you can watch a recording and download a PDF of the slides). During the webinar I received many questions, some of which we had time to answer but some which we did not.  Regardless, here are all of the questions and my answers.  I’ve organized them into the following topics:

  1. Long vs. Short Term
  2. Deferring Commitment
  3. Transitioning to Agile EA
  4. General

 

1. Long vs. Short Term

What about longer term? How do you see the role of EA on portfolio creation?  As you can see in Disciplined Agile’s Enterprise Architecture process blade one of the primary tasks of the EA activity is to consider the longer term. The enterprise architects will collaborate to do so, and will help bring their vision to their stakeholders in various ways.  As you can see in the workflow, the EAs will interact with the Portfolio Management effort (and many others).

How do you balance the needs of today vs. the needs of tomorrow? Would you wait for business to identify it as a priority, which may be too late… or look to get ahead of the curve and build something that can scale for anticipated growth? Experienced enterprise architects will definitely think about the long term needs of the organization. Disciplined Agile EAs will do so but will wait to act to the most appropriate time to do so.

 

2. Deferring Commitment

Can you point us to some places to read more about deferred commit? Deferring commitment to the last most responsible moment is a concept that comes from lean software development. I recommend the writings of Mary and Tom Poppendieck as well as the book SDLC 3 by Mark Kennaley.

If we defer commitment, how about if we need infrastructure, procurement and so on to implement that architecture? This deferring will delay the entire implementation? No. The advice is to defer commitment to the last most responsible moment.  You need to understand the needs of your stakeholders, which in Disciplined Agile include a wide range of people, and then act accordingly. The problem is that traditionalists will act too early and thus add unnecessary risk.

A good observation from Valentin Tudor-Mocanu is that to be able to defer decisions we need a design that separates the concerns (adaptive design).

 

3. Transitioning to Agile EA

Is there a strategy to change the mindset of enterprise architects on a large organization?  Yes. It first begins with education.  We offer a one-day workshop called Agile Enterprise Architecture: Disciplined and Pragmatic Strategies that does a very good job of working through the fundamentals.  The next step is coaching of the EA team themselves, and of the teams that they interact with, to help them gain the mindset and habits required to work in a more effective agile/lean manner.  We also provide such coaching services.

One specific question related to a service or consulting organization: One of the specific requirements for us to is to deliver architecture as a deliverable. How can agile can help us?  Can we apply sprints there?  Can we apply any architecture principles? I’ll assume you meant an architecture model as a deliverable. The answer is yes, you can easily create an architecture model in an agile manner. I highly suggest that you visit the Agile Modeling site and read the advice about agile architecture strategies and to agile documentation strategies.

 

4. General

Can you talk about metrics in agile EA and Architecture in general?  In the Disciplined Agile framework we suggest that you adopt a lightweight Goal-Question-Metric (GQM) approach to your metrics strategy. The fundamental idea behind GQM is that you first identify a goal that you would like to achieve, a set of questions whose answers are pertinent to determining how well you’re achieving that goal, and then the metric(s) that could help you to answer each question. In short, the metrics that you gather will vary based on your need.

Given that Feedback cycle plays an important role, why does DAD say “Reduce feedback cycle”? Is there a pre-defined cycle frequency?  You should find the blog posting Reducing the feedback cycle requires discipline to be an interesting read.

Some forms of architecture (UX/UI) need a different cadence than the delivery team follows. What is your recommendation for handling this… UX research, etc? I disagree with your premise. I’ve heard this claim in the past and it’s never held water with me.  About 10 years ago I wrote an article entitled Introduction to Agile Usability that overviews how UX activities can appear in the agile lifecycle.  The Lean UX community has clearly gone further than what I originally wrote so you might want to go poking around on the web a bit.

When the business case says “many years before payback”, doesn’t that usually mean that the business case is missing some important elements? (or that the org is really small) ?  My experience is that the business case is usually crap in these situations. There in fact a few things in the software world that may have a multi-year payback period, operating systems come to mind, but they are more the exception to the rule.  The problem with multi-year payback schemes in the software world is that the ecosystem changes so quickly.  During the several years it takes for payback your needs change, there are new options on the market, your organization structure and direction may change, and so on.

I realize I’m asking a history question here, but regarding deferring commitment, a superb method for this that I have often used in the past comes from RUP: architecture mechanisms. (I should know this but) Is this in DAD?  If you read the Enterprise Architecture process blade article you will see that it supports several strategies for capturing and communicating EA ideas such as reference architectures, models, architectural runways, interfaces, and many others. You might also find the Reuse Engineering process blade to be of interest.

 

Leave a Reply

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