/Tag: Portfolio Management

Sharing the Solution Domain Taxonomy

By |2015-04-23T10:17:18+00:00April 23rd, 2015|Enterprise Architecture|

Sometimes, Enterprise Architecture efforts fail.  This is no surprise to folks in the EA business.  This failure occurred slowly, back in 2007 and 2008.  But it did occur.  It took me a while to realize it. 

I had developed a method useful for Application Portfolio Management as well as for Service Oriented Architecture called “Solution Domains”.  The method is good.  It’s a framework and taxonomy for high level descriptions of software so that generalized services can be created AND so that the portfolio of applications can be rationalized.

The method is good.  But I failed to position it’s use in the appropriate enterprise program in the appropriate way.  I failed.  Not the method.  Where we used the method, it worked brilliantly. 

I’ve learned from my mistakes, but being unwilling to let a good thing go to waste, I’m sharing the Solution Domain taxonomy with the world.  It’s not patentable (I tried).  It is useful, however, because it is a part of a business method that supports Application Portfolio Management in a completely technology agnostic manner as well as Middle-Out SOA.

I’ve put the entire taxonomy on my Enterprise Business Motivation Model site at: http://motivationmodel.com/wp/application-portfolio-management-and-solution-domains/ 

I may return here, at some point, and provide further details on how it can be effectively used.  For now, back to work!

Video Podcast: How Microsoft Does Enterprise Architecture

By |2011-06-23T10:36:23+00:00June 23rd, 2011|Enterprise Architecture|

It is amazing how often I need to share the very basic concept of Enterprise Architecture with my peers, customers, stakeholders, and associates.  Microsoft’s customers often ask about Enterprise Architecture, and when our customers come to visit us in the Microsoft Executive Briefing Center, they are more frequently bringing their Enterprise Architects along for the conversation.  To help clarify our view of EA, I teamed up with the Microsoft Showcase team and Microsoft Studios to produce a podcast describing Enterprise Architecture. 

The podcast is located on the Microsoft IT Showcase site here.

I thought about including a transcript, but I don’t have one.  I mostly spoke from an outline.  If you have questions or comments on the video, please don’t hesitate to contact me and we can collaborate. 

Three word definition of Enterprise Architecture: Reduce Unnecessary Effort

By |2011-02-18T10:44:01+00:00February 18th, 2011|Enterprise Architecture|

I was speaking with a software architect, yesterday, after Martin Sykes, Mark West, and myself presented our ideas around Visual Stories to about 150 consultants.  He asked me about my role and when I explained that I am an Enterprise Architect, he asked what that is.  I got my chance to use my new three word definition of Enterprise Architecture: Reduce Unnecessary Effort.

This is the goal of alignment: to reduce unnecessary effort.  We find the things that could be done, and the things that should be done, but also the things that should not be done, and we use that information to influence the governance decisions in the business.  When the business “announces” a solution to a problem, we are there to vet that solution to insure that we do LESS unnecessary effort.  We may end up doing less work overall, or perhaps not, but a greater fraction of our project portfolio will be necessary (strategic) work. 

The difficulty in rolling this out is often the need to change IT governance practices that may be heavily entrenched.  As I’ve pointed out in the past, the aims of “demand management” in IT often run counter to the aims of Enterprise Architecture.  The goal of demand management is to “take on as much work as possible, doing the most important stuff first.”  As long as “alignment” is a factor in prioritizing projects, then there is no problem.  Unfortunately, that is rarely the case.

Most of the demand management programs I’ve seen, both in Microsoft and in other companies, are based heavily (or entirely) on ROI (Return on Investment).  As I discussed in my last post, ROI often prioritizes poorly aligned programs.  If Enterprise Architecture is to have any value at all in an organization, it is to help counteract this effect by prioritizing projects that produce a lower ROI, but do a better job of insuring that the organization meets their strategic goals. 

In Microsoft IT, there is a move to use a “balanced scorecard” governance mechanism that can balance strategic alignment as well as ROI in a single formula.  As a result, I have renewed hope that our internal governance mechanism will set up the correct priorities.  Tremendous credit for this work goes to my esteemed colleagues Munir Bhimani and Gabriel Morgan.  Perhaps, with the mechanisms they are setting up, we can finally begin to take the input from the “architects in the trenches” and include their insight in the process of deciding which programs should be funded, their scope, and elements of their solution.

And then, in our large, noisy, headstrong environment, Enterprise Architecture will be better positioned to “Reduce Unnecessary Effort.”

Inserting Architectural Governance into the IT Program Funding Cycle

By |2010-06-15T08:50:52+00:00June 15th, 2010|Enterprise Architecture|

People do what you pay them to do.  That much is clear.  In most businesses, if you pay (reward, incentive) your employees for performing a particular task, then the task will be performed.  Also in most businesses, people are busy, so if you don’t pay them to perform a particular task, it largely won’t be performed.

So in organizations where there is little or no tradition of governance, and where many people openly oppose the notion of having another person or team “telling them what to do,” how do you get people to sign up, show up, and put up?  You pay them.

I’m not talking about bonuses, and I’m not talking about personal rewards.  When dealing with the governance of projects within a business, I’m talking about requiring them to justify hours spent against a budget, and then creating controls that create and distribute the funds for that budget. 

A large number of IT shops use this mechanism for basic governance.

A primer…

Let’s say you have five project teams.  They all want to perform different projects based on what the business wants (or, as is often the case in IT, based on what IT believes that the business needs).  But there is no way that all of those projects can actually be completed in the coming year.  You can use priority to decide what to do, or you can use teams of architects to drill in to the project teams and determine what features will be built, and by whom.  But that doesn’t mean that the decisions made in advance will be followed.  Just because business leaders don’t want that ESB, does that mean that the developers won’t build it?

The rigor needed is to require project managers (and in some organizations, the project team members themselves) to “book” their time against a budget that has been set aside to fund their project.  So team one, that wants to build features A, B, and C, starts with an estimate the costs of that effort.  The architects and planners decide that team one should only build features A and B.  So they budget only enough money to build A and B.  Assuming that people are actually pulled off of projects when the money runs out, then project teams will have a built-in incentive to either deliver what they promise, or inflate their estimates so that the amount requested covers all of the desired scope, regardless of the executive decisions.

Now, in this environment, how do you add architectural governance?  Add architecture to the funding model, of course.

When a project is being considered for funding, take a look at specific attributes of the project.  If it is important, large, risky, or likely to need oversight, then it should follow specific rules for architectural governance.  (The rest of the projects, which will account for a large majority of the budget, do not require architectural governance, and can simply negotiate directly with their business stakeholders on the basis of ROI).

This subset of projects needs special governance, architectural governance.  That means that specific requirements are placed on the project as it is being conceived.  In fact, you may need a two-stage process just to get the project started: stage one to get the information in place to decide whether to do it, and stage two to perform the actual project, with a funding decision taking place in the middle.

The key requirements for deciding if a project should be performed will go far beyond the normal ROI calculation.  Large, risky, or potentially game-changing projects need to have architects fully engaged to help set the scope of the project, decide what enterprise assets will be improved or addressed, and focus in on stability, scalability, security, agility, and performance.  Information has to be collected about the components in other systems that need to be improved, so that careful dependencies can be taken.  Roadmaps need to be lined up because success may depend on many projects producing changes in many systems.

The flexibility that the business will have in “compressing the scope to reduce the budget” will be severely curtailed.  The ROI calculation will not be quite as flexible, as there will be a great deal of cost that the business cannot squeeze out. 

A team of architects needs to oversee this information gathering process, and needs to be present to defend the costs when the business tries to compress the budget or take short-sighted cuts.  The project needs to deliver value frequently, all the way to the customer, in a rhythm that increases confidence in the IT organization to succeed.  Only if all of these criteria are planned in, and carefully described, can the project get through the funding process and begin effort.

All the architectural review in the world can’t begin to provide the value that architectural governance during the funding cycle provides. 

Sometimes, to win the game, you have to be at the right starting line…