Stephen Cohen's thoughts on Enterprise Architecture : MSF

Does your enterprise architecture add up?

Stcohen — Tue, 06 Apr 2004 04:45:00 GMT

So you have an enterprise architecture ... How well does it work? Here is a quick test, a mere 5 questions, intended to help evaluate it. But first a few rules;

This is only applicable to DEPLOYED architectures. Generally, deployed means stable and used by at least 2 applications for at least 3 months. Of course you get valuable bonus points for having more than 3 applications deployed on a single enterprise architecture for 6 months or more.

The test, as well as its results will be most meaningful if you were involved in both the development and use of the architecture.

Finally, this test is intended to be a team activity (please include stakeholders). There may well be more value in discussing the questions than actually answering them.

Try to answer the questions concisely... I have some discussion of each question a little further down.

-----------------------------------------------------------------------------

Q1) how long did it take to field the last application in the enterprise ?

Q2) how much money was saved that can be directly attributed to the enterprise architecture ?

Q3) Which business activities have improved that can be directly attributed to the enterprise architecture ?

Q4) What IT processes have changed that can be directly attributed to the enterprise architecture ?

Q5) How has your enterprise architecture effected communication between the IT teams, the business managers, and the users of the products of the business ?

-----------------------------------------------------------------------------

That’s it. So, how did you do? First, did you meet the initial qualifications ? If so, consider yourself in the top 10% (ok I confess this number lacks any real scientific credibility but it 'feels' right to me ) of all organizations claiming to have an enterprise architecture. Many organizations are so beaten by change, either or technical or organizational, that they fail to maintain a stable base which an enterprise architecture may provide. Change will continue to happen but the architecture underlying corporate applications should seem more evolutionary not revolutionary.

Discussion …

1) The first question, worth 10 points, how long for the first application to be deployed on the enterprise architecture, is meant to provide several metrics;

Did you have value designed in?

Did you have participation from at least one application team?

Did you have BOTH short and long term goals in place as you built the architecture?

2) By tracking how much money was saved we can see if there is a clear and demonsratable return on investment. Ideally, ROI calculations will include the costs associated with both development and operation of the enterprise architecture. Give yourself 10 – points for an honest assessment and another 10 points if you have clear return.

3) Improvement in real business activities sketch an outline of value the enterprise architecture provided in the less tangible areas. Consider reductions in time spent working with partners would certainly be considered an improvement to the business but won't be captured in the ledgers. Nor will improved employee satisfaction if historically repetitive tasks are eliminated. 10 points for improvements to the business and 25 points for increasing employee satisfaction.

4) Finding a deployed enterprise architecture that did not have some associated change in IT process would be a serious red flag. – 50 points if you can’t identify the effects to IT. A healthy enterprise architecture breathes through the IT process. However if you did it add rigor in the form of reviews or milestones? Your cross application / cross domain issues surface more easily? Or are resolved more efficiently? Even if test become an equal partner with development and hardware infrastructure? You get another 5 points.

5) A sound enterprise architecture binds software development , hardware operation, and business management into a continuous feedback cycle. If your architecture has encouraged or enabled the organizations to interact in more positive ways, give yourself 20 points.

Now add your points up, write them on a piece of paper, and throw it away. This isn’t about the score. Just another opportunity to consider the value of a well executed enterprise architecture.

The slippery slope of enterprise architecture definition

Stcohen — Wed, 25 Feb 2004 04:28:00 GMT

Step with me if you will onto the slippery slope of enterprise architecture definition. I try to capture the boundaries of the enterprise in a single simple layered boxes-and-lines diagram. Relationships are conveyed through adjacency and separation helps define inappropriate lines of communications. While the definition is my preferred first deliverable it is based on at least three categories of gathered information and models.

Use Cases are great tools for capturing, analyzing and validating the activities of the architecture. They provide a simple illustration of the people and systems the enterprise cares about and the service or services it provides to its consumers,
Sequence diagrams of the activities that create and deliver these services, and
Org charts, phone directories, and management hierarchies of the organization the political, fiscal, and physical constraints imposed on it.

Developed incrementally, using each to validate the others. Each and every change cascades back onto the other models. There will be the temptation to leave partial sketches behind and start over. RESIST !! A few complete, cohesive, balanced visualizations are all you need for the first pass.

On safari for the ever elusive enterprise definition

Stcohen — Sat, 21 Feb 2004 21:15:00 GMT

Two skills have served me well while gathering information about an enterprise. First, the lessons it has been my pleasure to have learned from my customers and the many, many, bright practioners I have been lucky enough to work with. Second, the ability to forget all of those lessons and question everything.

When first going on an architecture safari the goal is to trust but verify. Even when working with knowledgeable guides, there are long stretches of boring research punctuated by sudden blasts of uncontrolled detail. Information seems to be everywhere. In the volumes of arcane regulations lounging quietly on the cubical shelves, in the patterns of worker ant like activity which continues as though you didn't exist, as well as the sharp witted proclamations bestowed upon you by high powered consultants who, after years of dedicated service have yet to deliver but are all too willing to tell you why they are failing. You need to take it all in, putting each item in context with its source and related each item with others to decide how much impact it will have.

Don't get me wrong, generally people really do mean to be helpful. They speak authoritatively; blissfully unaware of their own errors of omission. Although I find they are more likely than not going to try to TELL you the answer... with little regard for your actual question.

I have found myself working on my interviewing skills to address this phase of enterprise architecture. For the friendly sources I have taken to watching body language and seeking to engage them using their own words ... their terms not mine. Of course not all sources are friendly and those hostile few are generally more valuable, but care is required to manage the conversation. In these circumstance I find interrogation techniques used by law enforcement very practical.

Direct positive confrontation: “ I understand your issue with X but tell me how it fails to achieve Y”,
Developing a theme: “ … so far we have identified three failings of X but lets focus on the achieving the specific activity Y …”, and
Leading concurrence: “I know your approach is better but I need to understand it, could you describe N as it applies to Y?”

Throughout the information gathering process, without regard for source, understanding is more important than knowledge. Focusing on the business operations, not the activities of the systems, and seeking root cause for each issue identified have proven to be absolutely necessary. The need for more information never ends but your hunt for qualified, trusted, useful information will be time-boxed.

How do we define the scope of an enterprise?

Stcohen — Mon, 16 Feb 2004 06:38:00 GMT

How big is your enterprise? It turns out to be a very difficult question to answer. Consider this simple scenario;

You have a newspaper delivery route. Your supplier pays you as a contractor. You receive the newspapers each morning from another independent contractor. Each home you deliver to is your customer.

So what are the boundaries of this enterprise?

· Is it defined by an application to keep track of the number of papers received, monies collected from customers, and amounts paid to the supplier?

· How about the scope of control? As a delivery person you don’t control the content or layout of the papers so you can’t affect sales. You can’t control when the papers arrive nor can you “force” a customer to pay. The only control you have is over the actually transport and delivery of the newspaper from the point you pick them up to the time you drop them at door of the customers.

· Maybe it’s the data that defines the enterprise. You store customer records (name, address, billing status), bills from your supplier and invoices to your customers.

I believe the scope of the enterprise is actually defined by the scope of its vision. Continuing the metaphor, if all you care about is managing the funds of your newspaper delivery service then your scope is focused down to the necessary accounting system. Should you decide that your enterprise is going to grow to an organized community of news delivery people serving multiple providers and sharing resources across geographies? Now we have a much more complicated enterprise indeed.

As-is vs. To be

Stcohen — Sat, 14 Feb 2004 20:51:00 GMT

Many discussions of how-to-do architecture talk about modeling the domain 'as-is' then defining the 'to-be' state. In general I agree, clearly defining the problem before identifying the solution is a risk mitigation technique. By focusing on the current state you avoid artificially injecting constraints or driving change for the automations sake into the business.

While valuable for application architecture this really doesn't hold true for enterprise architecture. When establishing enterprise architecture it is your job to define the constraints. At the enterprise level we define boundary conditions in multiple dimensions. Political boundaries, fiscal limitations, as well as the vision and strategy of the business are captured ‘As Is’ to guide the individual projects.

Enterprise guidance is implicit not explicit. It creates an environment fostering growth over time. It's the applications that decide what the ‘To-Be’ implementation is for their portion of the enterprise. Applications are free to do as they please as long as they are well behaved citizens of the enterprise.

Shredding Requirements

Stcohen — Tue, 10 Feb 2004 18:58:00 GMT

I spent most of yesterday going through 60+ verbose PowerPoint slides and 45 pages of detailed requirements. You see I have a customer who has run into several issues rooted in their initial design considerations. They are a CMM level 3 organization with detailed procedures, voluminous documentation, and honestly it is not unnecessary. They build large, complex systems and their end users require structured documentation.

The requirements seemed to have been written after they selected and architecture and specific technologies, a serious no no. They had established nearly 30 requirement categories with low level must perform and shall provide statements. There is a proposed logical architecture establishing 5 plug-able service modules and a core services ‘bus’. Many of the requirements define object life cycle management and strive to maintain location transparency. This all smelled to me like a JINI and CORBA based approach. Not the most unreasonable thing to do … except they are working with an exclusively Microsoft development environment.

My first goal was to shred these requirements into something I could get my mind around. Focus on the “real” business requirements. Try to figure out just what where they trying to accomplish with location transparency? High availability and loose binding seems likely; both laudable goals for an enterprise caliber infrastructure. But I couldn’t reconcile the plug-able components. Maybe they were looking for High cohesion within each component?

Using my favorite mind mapping program, MindManger, I began re-sorting each requirement, deleting duplicated, identifying orthogonal requirements and pulling policy or hardware related items into an out-of-scope category. The result is a set of 11 services, each with 6 to 25 detailed, testable requirements. For many I have been able to map them to existing Microsoft technologies (COM+ Enterprise Services, the COM hosting environment, the Enterprise Information Framework, etc … ) effectively removing them as items to be developed.

My next task is to establish a few high level use case documents and a simple block and line architecture model to present back to the customer and hopefully validate my findings.