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.