Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

March, 2010

Posts
  • Inside Architecture

    Does app portfolio simplification solve the wrong problem?

    • 13 Comments

    As you may know, I agree with Roger Sessions that one of the value propositions of Enterprise Architecture, as it relates to IT,  is to simplify the IT application portfolio.  I believe that every application has a “cost to own” and adds to complexity.  By reducing the complexity and size of the portfolio, we can free up resources that are so desperately needed for innovation.

    One of the primary patterns for application portfolio simplification is to find two similar business units that use two overlapping applications, and change the processes in one unit, and change the features of one application, so that both units can use the same application.

    appmerge1

     

    There are two changes here.  You have to change the business processes of at least one of the teams (probably both teams), and you have to change the features of one of the applications, which usually means bring together the data sets as well.  That’s a lot of change.

    But as an enterprise architect, I get to look beyond the bounds of IT.  So, let’s take that viewpoint.  Now, we don’t have an IT problem.  We have a business complexity problem.

    As an Enterprise Architect, wouldn’t it be simpler to simplify the business itself?  Not always possible, but it can be done.  In those cases, there can be less overall change if you simply merge the business functions. 

    appmerge2

    People get very attached to their applications, and it is tough to convince an executive to take on the cost of making all of the changes to merge applications.  In some cases, application portfolio simplification can be done best through “business function portfolio” simplification.  In other words, the case is more compelling to merge the business functions instead.

    What say you, gentle reader?  Have you ever worked to merge business functions?  What was your experience?

  • Inside Architecture

    Azure – Practitioners Guides

    • 0 Comments

    I think that this post by Bill Zack is pretty useful. The post lists resources for everyone who wants to learn more about Azure and the Microsoft “Platform as a Service” strategy.  Please feel free to share the link.

  • Inside Architecture

    How the Program Management Office Views Enterprise Architecture…

    • 5 Comments

    There’s an interesting analysis available through the PMO Executive Board on “Project Interdependencies.”  In the problem statement, the author correctly observes:

    As the volume and size of projects grow, the old problem of managing project and program interdependencies is becoming more acute: three quarters of PMOs consider “managing interdependencies” to be one of their most critical program management challenges.

    First statement is cool.

    Unfortunately, the next concept is somewhat troubling to me.  According to the author, the solution to this problem is one of process 

    “… the ability to track and communicate project interdependencies boils down to two essential managerial disciplines: good risk management and clarity of communication with senior executives.”

    In other words, we can track and communicate interdependencies better if improve our ability to manage risk and communicate interdependencies.  Is that argument convincing to you?  Seems pretty circular to me.

    Digging a little deeper

    Let’s take a look at the “project interdependency problem” for a minute.  If projects had no interdependencies, there would not be a problem.  However, if one project must complete before another one can deliver value, then there is an interdependency. 

    This is a problem because we may not know which project is the “critical path” project, so we may not do a good job of accounting for delays or cost overruns in the “source” project that can ripple across many other projects.  In that aspect, understanding the interdependencies is a CRITICAL problem for the Program Management Office. 

    But let’s dig a little deeper.  What causes projects to be interdependent upon one another?  According to the same analysis, the factors to consider are:

    1. data,
    2. artifacts or deliverables,
    3. technical functionality,
    4. infrastructure capabilities,
    5. milestones, and
    6. end-user commonality.

    Think through the list above.  How many are NOT architectural?  You could say that end-user commonality is not architectural, if you were to exclude business architecture from the discussion, but once you examine the kinds of models developed in an Enterprise Architecture context, 100% of the types of interdependencies chartered in these different projects are visible in, or predicted by, the architecture of the systems.

    Improving the advice

    I am not saying that a PMO shouldn’t be concerned with Interdependency management.  It is not the job of Enterprise Architecture to track, communicate, and drive the flow of the project portfolio. 

    What I am saying is that the advice needs to be extended.    The second sentence above, and the entire presentation to follow, needs to recognize the clear dependency that the PMO takes, or should take, on the Enterprise Architecture team to identify, review, minimize, and prioritize systemic and project interdependencies. 

    In other words, the second sentence above would become:

    “… the ability to track and communicate project interdependencies boils down to three essential managerial disciplines: timely development and delivery of Enterprise Architecture, good risk management and clarity of communication with senior executives.”

  • Inside Architecture

    Should IT run “like a business” or “like a non-profit?”

    • 8 Comments

    Why is it so hard to run IT like a business?  Because, I can choose to be a customer of a business, and I can choose not to be a customer.  Businesses don’t mind because there are usually lots of potential customers, so getting a market share of 1% can lead to a great deal of success.

    IT does not have that luxury.  If IT is to run like a business, then its services have to be consumed by some or all of the business units.  It has to win MOST of the time that IT is in competition with an outside vendor.  The more successful any particular IT service is, the less expensive it gets because much of the overhead is spread out over many customers.  Economy of scale.  This is how businesses work.  Unfortunately, there is not an infinite supply of business units!  IT does not have a broad array of customers to compete for.  IT has a small handful of customers, and that is a problem.

    If there are only three business units interested in a particular IT service, and two of them sign up, you have a 66% market share.  That’s great… until one of them decides to outsource.  Then you have dropped from a 66% share to a 33% share.  If I was an automaker, or even a consulting firm, and I have a product line that goes from 66% to 33% market share in a year, I’d go through organizational chaos.  Most businesses cannot scale back that quickly and neither can IT.  In addition to the human cost, financial costs for the service’s remaining customer will soar.

    You also have the fact that IT works for the same CEO as the customer (business unit) does.  That means the CEO can issue an edict, and both the business units and IT must comply.  If the business unit chooses not to comply, but IT does comply, then the business unit has little choice but to outsource. 

    You could be thinking “but how can a business unit ignore the CEO?”  For many organizations, accountability to the CEO’s edicts are governed very differently within IT than they are within the lines of business.  That is because IT is a cost center, while a line of business is a profit center.  Profit centers are given a LOT more flexibility.  Therefore, IT has a constraint that few successful businesses have: it has to comply with rules that its competitors do not have to follow. 

    Running IT like a business, with these economic and market constraints, is nonsense. 

    The more rational approach is to run IT as a two-headed organization.  One is a governmental agency, able to levy and collect taxes and responsible for providing uniform services to all citizens (the business units).  The other is a non-profit service provider that is under contract to the government, providing subsidized services to those citizens who need them.

    The Governmental approach

    Whether we want to admit it or not, this is often how IT runs.  The cost of IT is simply deducted as a corporate expense.  In other words, the cost of running IT is a tax.  In large organizations, a simple formula may be applied to determine the amount of money each business unit needs to pony up.  In Microsoft, your business unit pays a flat fee for each employee or contingent staff member that you have.  For that money, you get a wide array of networking, collaboration, security, and information management services that you don’t even think about.  The stuff is free and it runs.

    The Subsidized Non-Profit Service Provider approach

    While there are services that we all need, like a secure network and good collaboration and messaging tools (like Exchange and SharePoint), there are also services that some teams need while others really do not. 

    For small companies, or companies with very simple business structures, this is not even an interesting conversation except to say that the line-of-business funding pays for line-of-business software.  It is still subsidized, because once the line of business application is running, the “government” side covers many of the operating, networking, and data management costs.

    However, for a very complex organization like Microsoft, business-service funding can be a good bit more difficult.  That is because any single service may have five, ten, fifteen different business units that could, potentially, be their customer. 

    This is where the “non-profit service provider” idea starts to take shape.

    Here you can use some principles of business, like setting up a mechanism to insure that the business units who make the most use of a service are the ones that pay the most to use it. 

    For example, let’s say that your company is a retailer that operates branded stores (like Gap and Old Navy).  Your company also sells uniforms to hospitals and health care institutions.  Marketing to these two different markets is quite different.  The marketing team for the branded stores will directly consume individual customer data at a far higher rate than the marketing team for the uniforms business.  Therefore, they should pay more for the “Customer Marketing Profile” services.

    It is a non-profit model because you are billing the customer, but you are not billing them for the full costs, and you cannot make a profit on it.  The advantage of running IT this way is that the services provided are always competitive with market rates (due to the subsidy), while IT itself is buffered from the chaos that ensues when a business unit decides to use the cloud for a service and stop paying IT to do the work.

    Conclusion

    For years, we’ve heard the old saw: If only we could run IT like a business!  But really, we cannot.  IT does not have a market the way a business does, and IT cannot ignore the edicts of the CEO like an outside service provider can. 

    It is far better to make a clear distinction between the services that need to run as cross-organizational “platform” services and those that support one or more lines of business.  The services that support one line of business can be funded by that line of business.  The ones that support many lines of business can use a “non-profit” model like I outlined above.   These are really two variations of the same model: the subsidized non-profit service provider.

    One is government, the other is non-profit.  Both live together under one IT umbrella. 

Page 1 of 1 (4 items)