//Agility, Feedback, and Enterprise Architecture

Agility, Feedback, and Enterprise Architecture

I blogged a few days back about agility in EA: Deliver Early, Deliver Often, Take Feedback, Iterate. 

I’ve said often that this concept is just as applicable in business as it is in technology. 

Enterprise Architecture is supposed to be the bridge between business and technology.  Let’s think about the concept of a bridge for a minute: we take changes on one side and translate them into changes on another. 

Can that work both ways?  Most of the time, the descriptions are one way: we take changes in business and translate them to technology, but I believe that we lose value if we Don’t take changes in technology and translate them to the business.

That’s an easy thing to say, because there are two definitions of ‘technology.’  If we talk in generalities (technology trends, new capabilities, new threats, new opportunities), then taking technology to the business is the job of IT and the CIO anyway.  That is very important, but not what I’m getting at.

There are innovations that occur deep in the bowels of IT that stay there.  They never come back to be visited, or understood, or reused, or leveraged, in the business.  That is because the business, in general, has no way to get that feedback.

An example would be good.

For a while at Microsoft, I worked with the Legal IT division.  Their charter: provide tools to the lawyers and paralegals in the corporate law department.  They had tools for discovery and document management and workflow… but no tools for clause management.

Clause management allows attorneys to compose legal documents from pre-written ‘template’ clauses.  With a clause management tool, you create a workflow that creates these clauses, and you can update them in all downstream document templates by updating them in the clause management tool.  No more situations where a contract is signed using ‘old’ clauses when ‘new’ ones should be used.

Clause management is something that attorneys want, but never get around to paying for. 

That said, as I moved into Enterprise Architecture and started looking at tools used by other parts of the Microsoft business, I found three clause management tools.  Not one of them was written by the legal IT team.  Most of the attorneys had no access to them.  They were used by the business teams to keep track of the clauses that the attorneys had approved so that a new contract could be created quickly.

In Enterprise Architecture, we want to be able to tell the Legal department that a team, in the company, wants to build a clause management tool.  Not only can they vet the requirements, but we can make sure that the resulting tool would be useful to the attorneys for many other businesses.  In other words, actually connect the tools to the users who should be using them, not just the ones who are paying for them.

And this is one place where Enterprise Architecture can help.  By mapping the features of a new system to a consistent framework that we call ‘Solution Domains,’ the Enterprise Architecture team is able to draw attention to the fact that a new project (or an existing app) meets needs in many areas.  We can see overlaps before they happen, and overlaps that already exist.  We can get the right constituents into the room and make sure that the correct voices are heard.

This is a form of ‘feedback’ in the same agile sense.   Our customer is the enterprise.  It is an odd organism… completely capable of performing excellent work in one area, that another area is oblivious to.  When the enterprise asks, Enterprise Architecture needs to be there to bring people together, get the innovations surfaced, and develop tools that everyone can use.

By |2007-08-26T10:49:22+00:00August 26th, 2007|Enterprise Architecture|6 Comments

About the Author:

President of Vanguard EA, an Enterprise Architecture consulting firm in Seattle focused on the Pacific coast of the US. Nick has over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

6 Comments

  1. Sam Gentile August 28, 2007 at 12:57 pm - Reply

    My news favorite drink: A StarBucks Black Eye . SOA Service Oriented Infrastructure Building Justifying

  2. R2D2 September 9, 2007 at 12:31 pm - Reply

    Nick,

    Any comments on feature identification and feature analysis ? Using Customer VoC and building the feature map ? What are your thoughts on using "lean" or ‘going to gemba’ as they say.

    We used this approach for a feature analysis exercise. Maybe I would refer back to some artifacts I wrote on this if we can take this thread further ?

  3. NickMalik September 10, 2007 at 1:06 pm - Reply

    Hello R2D2,

    Feature analysis is a technique used to understand the alignment between features and how they map to the needs of the business.  Useful when building projects.  However, when working against the stable abstraction of Capabilities, this work slides below the radar.  

    I’m working at the level of the enterprise requirements for integration.   This technique, useful for project requirements analysis, is not aligned specifically with SOA.  In fact, it can be used for non-SOA designs just as effectively.  Therefore, I’d say that feature analysis is, in this case, an independent practice from SOA.

    As far as ‘going to gemba’ and lean, you are more familiar with the details of lean manufacturing than I am, by the sounds of it.  I had to look up "going to gemba" online.  

    Lean manufacturing is about eliminating waste and creating an efficient and supportive environment for making things in a useful and standard way.  In my present role, I would move that effort over to the folks who are concerned about development process, and I would focus instead on IT alignment and the future of integration.

    If I was to use the analogy of a team of explorers hacking their way through the forest, then the ‘lean’ practices would focus on cutting the path correctly while I wish to focus on cutting the correct path.  Both are necessary.  But they are independent considerations.

    — Nick

    P.S. Say "hi" to Luke Skywalker for me ;-).  

Leave A Comment

seventeen − 11 =