Architecture

Enterprise Architecture Benefits

by

Author: Alex Matthews – Twitter: @remembermytweet Here is a free, un-formatted slide deck that describes some of the key benefits that can be gained from applying Enterprise Architecture. It can […]

Positioning an Enterprise Architect for Success

by

As I found in our Enterprise Architecture team in Microsoft, each time an Enterprise Architect is assigned to a specific area of the business, each one has a unique “engagement” with their stakeholders.  In very large organizations (like mine), there may be many different IT units as well as many different business units, all involved in a particular strategy.   Each situation is different.   This leads to a common problem that can framed with two questions:

  1. So how do you know if your Enterprise Architect is doing a good job?
  2. How do you set the right expectations to position that Enterprise Architect for success?

A Model for Positioning an Architect

We developed a simple grid that helps to position the EA with respect to a specific area of the business.  The two axes of the grid are: Architectural Maturity of the “segment” and Maturity of the Architectural Engagement itself.  Within each cell, we put a description of “what we want the EA to do” if they find themselves in that position.

Note that maturity of the engagement is a measurement of a relationship: specifically the relationship between the “business customer” and the Enterprise Architect.  Architectural maturity of the segment is measured against both the business area and the IT groups that they use (see below).  You need to measure the maturity of BOTH variables in order to understand what an Enterprise Architect will need to do to be effective.

image

Note that the Architectural Maturity axis has four levels, cryptically described as “Level I” through “Level IV”.  This is a reference to our internal maturity model, which I’m not at liberty to share in detail. 

The broad strokes are:

  • Level  I – architecture is not a trusted and well-understood role in business change or IT programs.  (This includes business, information, solution, and technology architecture).
     
  • Level II – architecture is used and their processes are defined, but not consistently and not well. 
     
  • Level III – architecture is performed consistently and is part of governance as well as some portfolio planning activities.  The business stakeholder does not take ownership of driving the funding and execution of the roadmaps developed by the Enterprise Architect.
     
  • Level IV – architecture is performed consistently and is involved in planning and governance.  The business stakeholders involved in funding and overseeing the business changes themselves are engaged with enterprise architecture, have been key in developing the roadmaps, and follow through with regular updates to the future state models and the roadmaps.  In addition, they decide on which initiatives to use BASED ON the content of the roadmaps. 

 

Using this model

I’ll provide two scenarios to illustrate how this simple grid is used. 

In Fabrikam, we are Enterprise Architects.  Fabrikam manufactures and distributes consumer electronics.  There are six divisions that manufacture different kinds of products (kitchen appliances, television and radio, automotive, etc). Let’s say that we have 18 Enterprise Architects in our EA team.  Fabrikam’s EA has divided into three working groups, each with six architects.  Maria manages one of these teams, and has six enterprise architects working for her.  Her team focuses on addressing business issues related to supply chain management. 

Maria is performing an annual review for two of her architects.  They are Tomas and Jai. 

Case 1: Tomas

Tomas is working with the kitchen appliance team.  This is the oldest division in Fabrikam, and they have their own IT group that has been stable for many years.  That team has established processes for IT architecture but no business architecture.  Their architectural maturity is Level III.   Tomas just moved over to the kitchen appliance division from the television and radio division.  He is a well established architect with years of experience, but the kitchen appliance team is just beginning to get to know him.  As a result, the maturity of the engagement is “Useful.”  

The intersection of these axes has the following text:

  • Engage in existing review and governance processes
  • Engage stakeholders in cross business decisions
  • Collect current state data

Maria can set expectations with Tomas and with the Kitchen Appliance division.  Tomas will be expected to engage in existing governance and review processes.  He will be expected to work with business stakeholders in the kitchen appliance team as well as other divisions to address shared opportunities, capability overlaps, and strategic prioritization.  He will be expected to collect current state information models, system models, technology models, and business strategies for the EA repository.  He will be measured on his ability to deliver on these expectations.

Case 2: Jai

Jai is working with the automotive division.  This is the newest division in Fabrikam, and they are just beginning to roll out their first set of after-market automotive radios and CD players in the North American market.  Their IT division is small and rather chaotic.  Their architectural maturity is Level I.  Jai has been working with the automotive division for about two years, and has repeatedly earned recognition from their business leaders for his skill and depth of knowledge.  The maturity of the engagement is “Influential”.

The intersection of these axes has the following text:

  • Demonstrate EA specific methods and deliverables
  • Drive the scoping, approval, and oversight of an enterprise-relevant project

Maria can set expectations with Jai and with the automotive division.  Jai is expected to demonstrate EA specific methods and deliverables.  The teams know him and trust him.  He can demonstrate how EA can be valuable by simply doing the work and showing how valuable the results are.  Due to his level of influence, he can work with the business to invest in an area of improvement that will benefit the entire enterprise (for example, a project to improve the distribution of finished goods to retailers), and then work with the IT teams and business stakeholders involved to get the project launched and oversee its development.  Jai can be measured on his ability to deliver on these expectations.

Conclusion

In small organizations, Enterprise Architects can be “heros” and just “do what works,” but if you are trying to develop a mature EA program, each architect needs to have specific goals and specific deliverables that they will be expected to deliver.  This kind of model, we found, is useful for helping each architect to position themselves and their role in the organization.

Enterprise Architecture & Systems Thinking

by

Author: Alex Matthews – Twitter: @remembermytweet (See also the Enterprise Advocate’s post on Enterprise Architecture & Complexity Theory) I just discovered this brilliant presentation by Dr Russ Ackoff. In it he […]

Why the Yammer Acquisition Means Almost Nothing to Your Enterprise

by

I would argue that while the acquisition is great for Microsoft, and absolutely fabulous for Yammer’s investors, for most enterprises it’s not really a net positive and potentially, could be quite negative depending on your company’s disposition towards the cloud.
Continue reading →

On My Move To Consulting Services

by

This is the official announcement.  After seven years of providing Enterprise Architecture services to my own company, Microsoft, I’ve decided to move into the Microsoft Consulting Services division and offer my Enterprise Architecture skills and experiences to other companies through Microsoft’s acclaimed world-wide consulting services division. 

Nick Malik… Enterprise Architect for Hire.

I’ve been a consultant before.  In fact, in the 26 years since I graduated from college, I’ve spent more time in consulting than as an employee.  In some ways, I’m coming home.  However, I’ve not consulted through Microsoft’s consulting division before.  I expect that customers of Microsoft expect different things of their Microsoft consultants than they do from their management consultants or software development consultants (the roles I’ve played before).  I have a transition to make, and in all honesty, I’m both excited and nervous about the change.  After all, I’ve been working in one environment (Microsoft IT) for the past eight years.  I expect that moving “outside the bubble” will be a move back into the real world… a world that has changed dramatically since I was last there.

Microsoft’s internal culture is all-encompassing.  First off, not many people have the opportunity to work for such a large IT division.  Microsoft IT has 4,000 full time employees and thousands more consultants and contractors.  There are offices in 100 countries, six large scale redundant data centers, and massive deployments of bleeding edge technology.  Microsoft IT is Microsoft “First and Best Customer,” which means that we get the first crack at new technology, whether it’s ready or not.  For example: Thousands of Microsoft employees are using Windows 8 for their normal working environment, and yes, our helpdesk supports Windows 8.  We have large teams, and many roles, and an IT budget in excess of $1B.  No, Microsoft IT is not a typical IT shop.

For all the excitement of working inside the cauldron of Microsoft, the noise inside the bubble drowns out the sounds of reality from outside the bubble. To counteract this,  I have always made an effort to reach out and speak directly to customers of Microsoft software and exchange practices.  I am a member of a small minority of IT architects who are engaged in that way.  Most of IT is focused on serving the large and needy community of companies known as Microsoft. 

That doesn’t mean that Microsoft IT is sheltered.  Far from it.  We have strong relationships with key partners and each of the large OEMs.  We work closely with some large customers as well.  Microsoft IT folks are part of those partnerships and there is continuous contact.  That said, the majority of contact between MSIT and the “outside” world is in direct support of our partners.  Let’s not forget that it is also valuable to speak with people who are NOT involved in making Microsoft successful.  To that end, I’ve been engaged to speak to folks from financial services, oil and gas, retail, government, and many more sectors.  Each wanted to know about some aspect of Microsoft’s internal architectural activities.  Each was willing to share with me their experiences, and their techniques, for developing Enterprise Architecture.

I always got a great deal of energy from these contacts.  In some sense, they were the highlights of any week where I got a chance to present to, and listen to, and learn from, our myriad customers from all over the world.  And that is why I’m making this move.  I’m going after the thing that I enjoy doing the most: providing value directly to companies and organizations around the world.

What does that mean for me?  It means that I will spend a good bit more time in airplanes and hotels.  It also means that I will be working continuously in new situations, trying to add value as an EA in different companies, in different ways.  It also means that I may get something started and not be around to see it come to full fruit.  I’ll miss that part. 

What does that mean for you?  If you are a company or agency that needs an Enterprise Architect, and you’d like to have me visit and spend some time with you, please drop me a line through this website and I’ll see what I can do to arrange things. 

I’m hanging out my shingle.  Open for business.

image