Inside Architecture

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

December, 2007

Posts
  • Inside Architecture

    RIP Netscape

    • 2 Comments

    It has been a long road towards the end of Netscape.  Every worthy competitor deserves an honorable farewell.  Now that Netscape has announced the end of support for the Netscape browser, as of February 1, 2008, it is time to sound the bugle and offer the 21-gun salute.

    Netscape is being laid to rest. 

    Good night.

  • Inside Architecture

    Measuring Risk in Application Portfolio Management

    • 1 Comments

    I decided to take a few minutes of my vacation time to catch up on my reading, and I read through Mike Walker's article on MSDN on APM and EA.  It is an interesting and useful article. (I'd give it a B-).

    One thing that I'd like to highlight in the practice of application portfolio management is that of risk management, an area that Mike implicitely touches on, but which I believe is fundamental to the business case of APM.

    You see, there is nothing wrong with owning a bunch of stuff.  Think about it: how many chairs does your company own?  How many desks?  How often does the company spend money to replace every chair in every office?  If your business is typical, the answer to that question may very well be "never."

    Yet, we do see projects where a company will replace four billing systems with a single billing system.  That happens.  Clearly, owning an application portfolio is different than owning an inventory of assets.

    Key among the differences is risk... especially risk to business continuity.  There are many other factors, of course, and Mike covers some of them quite well in his article, but I want to focus on risk and risk management.

    There is a substantial intersection between Application Portfolio Management and Risk Management.   However, I suspect that some folks who read this may not be aware of the area of risk management.  From wikipedia, here is a fairly good definition:

    Risk management is the human activity which integrates recognition of risk, risk assessment, developing strategies to manage it, and mitigation of risk using managerial resources.

    The strategies include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk.

    By way of example:

    When you look at an inventory of chairs, you have risks.  If a chair gets old, and breaks, and an employee is injured, then the business faces insurance claims.  Morale suffers.  Productivity may decline due to lost work time and morale.  If the incident is public, then the company's reputation may suffer.

    Managing that risk involves understanding the kinds of things that can go wrong (falls, wounds, productivity decline, etc) and determining the factors about a chair that may lead to them (poor condition, missing parts, wobbling, etc).  If you collect this information about your inventory, and then you group your chairs according to these attributes, you might get a few classes of chairs: (excellent, workable, frail, dangerous). 

    With each category, you can determine the risk to the business for owning it.  Clearly, the risk to own dangerous chairs is higher than the risk to own workable chairs.  While it doesn't make sense to replace every chair, these statistics can provide an excellent business case for replacing the dangerous chairs (right away) and the frail chairs (over a finite period of time).

    We use essentially the same process for applications.

    What are the things that can happen to the business if an application fails?  Let's list out those things, and then create a set of attributes that an application has that will help to differentiate some applications from others.

    Risk scenarios --> Attributes --> Data collection --> categorization

    Within each category, you can determine the risks to the business that need to be mitigated.

    Note that you can have many heirarchies, many categorizations.  You can group applications by their lifecycle stage (Strategic, Core, Maintain, and Sunset), and that is certainly useful for combining APM with PPM.  In other words, it is useful to know how much of your planned budget is devoted to improving strategic applications. (Mike mentions this in his MSDN article, with different definitions that we don't actually use internally in Microsoft IT).

    Another useful categorization is application impact on operations.  The attribute to measure is  the speed at which a failure would impact operations of the business:

    • Instant (<6 hours)
    • Immediate (<2 days)
    • Rapid (< 10 days)
    • Serious (< 60 days)
    • Corrosive (within 9 months)
    • Hidden (gradual impacts on quality of customer experience or regulatory compliance)
    • Competitive (no impact on operations, but potential impact on ability to compete)
    • None (no one will miss this app if it goes away)

    This is far more useful than a subjective measure like "strategic" or "core" when determining the value of investment in an application, and it also shows something else as well: the serious problems that may arise from a lack of investment.  

    A terrific example was described in CIO magazine a while back, describing a situation where Comair Airlines kept putting off investments in a new crew management system, only to have the system crash during a heavy Christmas season that literally grounded the airline.

    No one in the business would have considered a crew scheduling system to be 'strategic' and so an investment portfolio that breaks things down by how 'strategic' an application is would not have favored the replacement of that application.  On the other hand, a categorization that captures the application's impact on operations would clearly have placed that application in the Immediate category. 

    Of course, correct categorization is only the first step.  Now you have to determine the risk of failure.

    Categorization --> risk of failure --> cost to business --> priority for mitigation

    By determining how likely an application is to fail, based on its risk categorization, you can select the applications that most need attention.  Now, that attention does not have to involve a rewrite.  There are lots of ways to mitigate risk.  You can move the risk by making someone outside the business responsible for handling that business capability.  You can reduce the risk of failure by introducing redundancy or failover.  You can reduce the cost to the business by moving non-essential decisions off of one application and onto another, more reliable, application. 

    Mitigation review --> Comparison of alternatives --> investment in mitigation

    I am not an employee of Comair, and I have no desire to criticize.  Their case is very public, but there are many more failures in IT that impact operations that are not so well described.  I refer to their misfortune as an example for us all to learn from.  In that vein: perhaps if there were a graph that showed the amount of investment against high risk applications, as opposed to the amount of investment against 'strategic' applications, then it would have helped to seal the business case for mitigating, and ultimately preventing, the heavy losses that the company faced when IT failed to keep the system running.

    The key here is that IT has to work closely with business, something that IT folks are not very good at and that business folks often fail to understand the value of.  But by showing that some applications deserve mitigation, and by working as partners to reduce the risks faced by those applications, the business will willingly invest in IT the mitigations that are needed.  This is the visibility gap that APM can fill.

    Success requires a conversation between IT and the business, one that Enterprise Architecture must foster.  And this is one area where EA and APM intersect.  One of many, but an important area that we must not forget. 

    EA + APM + Proper Measurement = Risk Management

  • Inside Architecture

    Measuring the agility of a SOA approach

    • 1 Comments

    I'm thinking about the business case for integration again... (still).  We talk about SOA providing a benefit by being more agile.  In other words, if you have a SOA infrastructure, you can change to meet the needs of the business in an agile way.

    Here's how to prove it.

    • Step 1: create a metric
    • Step 2: use the metric against two projects, one with SOA and one without.
    • Step 3: present differences.

    Step 1: create a metric

    You need to create a metric for the "IT Agility" recognized in the architecture.  This will provide you with a baseline to compare radically different projects on different architecture.

    IT Agility metrics are unusual.  In my view, this metric would relate the speed by which a change occurs with the complexity of a change. 

    Literally: Agility = Change Complexity / Change Duration.

    With a metric of this kind, you can compare the agility of two approaches: say non-SOA distributed systems vs. SOA distributed systems. 

    Measuring the speed of a change is not too difficult.  Time of request to time of delivery.  The other half is a bit harder.  Measuring the "complexity of change" is an interesting problem, but not intractable.  Certainly, there is cyclomatic complexity, but I don't think that says anything about the architecture.  It is too algorithmic and quite dependent on the language.

    Change Complexity = (architectural depth factor) * (process breadth factor)

    Think of this like the area of a rectangle: "depth in the architecture" times "breadth in the process" equals "area of the change." 

    Architectural depth is the number of LOGICAL layers of your system that are impacted by the change.  Logical layers could be a simple list.  I like this list: user experience, business process, business rules, information storage, information integration, but you could use your own list, as long as you are consistent.

    Process breadth is tricky, since processes include processes.  I'd say that the breadth of a process is a sum of the number of distinct roles involved in the process, and the number of hand-offs of responsibility from one role to the other. 

    Process breath = (number of roles) + (number of handoffs between roles)

    Now, with a metric of this kind, you need to use it to measure something... that the next section.

    Step 2: Use the metric against two projects

    Find two projects in IT where you can get your hands on the project requirements and timelines, for each update.  Project 1 has to be a non-SOA project, while project 2 has to be a project that was SOA from the start. 

    If you cannot do this, then you need to create a SOA Proof-Of-Concept project.  I'm assuming that you have some SOA systems in place already, but that you need to show value for the approach.

    If you have no SOA Proof-of-concepts (POC) yet, stop here.  I cannot help you.  Go get a POC going.

    Assuming you have a SOA POC, and assuming you can get the numbers for another system across it's lifespan...

    For each type of app, answer these questions

    • How often in the past 5 years has this business application needed an update?  (frequency of change)
    • How long did each update take? (duration of change)
    • How complex was the change? (see above section)
    • Are there other applications that do the same thing in your company?  (If so, include them in a generic category, like "Order Management") 

    Step 3: present differences

    Now you should be able to make a value-add comparison for the SOA vs. Non SOA projects and, assuming folks like me are right (no promises), you should be able to show that SOA projects are more agile.  That presentation needs to look good, and have the right information in it.  Don't assume everyone will know what to do with your recommendation.

    Special considerations for rip-and-replace projects

    Note: if the project you picked is part a "rip and replace" space, you need to do a bit more work. 

    A "rip and replace" space is any generic category of software (or solution domain) where the business invested, for the past few years, to remove an existing system and replace it with a new one.  Note that a R&R project doesn't need to be successful to be part of the problem, but clearly failures are easier to ignore when calculating the agility of the solution.

    For the sake of this comparison, avoid any projects in your comparison that have significant rip and replace projects against them. 

  • Inside Architecture

    The battle for the net-top heats up

    • 2 Comments

    Sometimes, in a long struggle, a goal that was strategic one day, becomes unimportant later.  This happens when some underlying assumption is challenged, when some previously secure resource becomes unavailable, or when the behavior of large groups of people shifts.

    hamburgerhill (Caveat: my views are my own, and may or may not be shared by my employer, Microsoft.  Investors, customers, partners: please, do not make financial or purchasing decisions on the basis of my opinions.  Nothing I say is "official."  God forbid.)

    That doesn't mean that the battle was lost... just that its strategic value is lost.  Winning that battle was hard-fought, and valuable at the time, but that battle, whether won or lost, just isn't as important any more. 

    For years, Microsoft has fought to put the most software onto the desktop of every personal computer in the world.  It is no secret that "windows on every desktop" was a rallying cry for this company for a while.  Although we are not so focused on a single product anymore, we still want to get our products on as many machines as we can, and machines into as many homes as possible.  That drives adoption, which creates a de-facto standard, and creating a compelling "virtuous cycle."

    We've been criticized for this strategy.  We've been lauded for this strategy.  We've been sued over this strategy.  We've been successful because of this strategy.  Microsoft software on every desktop! 

    But now I'm going to venture an opinion... a prediction of the future.

    In the future, winning the desktop won't matter as much anymore.  That goal, in the coming decade, will gradually decline in importance.  Putting a bunch of software on every desktop will be nice, and it will earn a lot of money, but, IMHO, it won't fund the next level of growth for Microsoft. 

    A new battle has emerged, one for the hearts and minds of the future generation: the generation of the digital native.  This is a battle of love and passion and inventiveness, a battle to earn the good will and the respect of a billion people.  A battle we cannot lose.

    Our past is based on the desktop.  Our future is based on the net-top. 

    What is the net-top?  The net-top is the Internet equivalent of the desktop, a grand shared space where all applications are installed already, and you pay for only what you use.  Where ultimate choice drives the day, where small players and large players alike have an much more even playing-field.  Where it doesn't matter if you live in China or India or Brazil or the USA... you get the same applications, available in the language you choose, and you can choose which ones to use because they are all already installed through the web and Silverlight and services.

    The net-top is the new surface of computing.  It is the Internet, plus service, plus software that is needed on the device to make up for the inherent frailty and constraints of the network.  It is neither open source nor proprietary.  It is not a browser.  It could be a mashup surface that provides access to every internet software+service application, already installed (even big-bad Microsoft's services), along with access to the virtual storage needed to hold the information. 

    (Note: Hosted desktop services are part of the net-top, but not all.  I'd start there, but my definition far exceeds the hosted desktop solutions that are currently available).

    I believe that, eventually, the service is all that will matter, and the download of software to the desktop will be both free, and very simple to do.  It won't matter where the desktop lives: on a laptop or a hosted desktop or a PDA or a telephone or in a car or woven into the material of your winter coat.  What will matter is the service.  Data will be "in the cloud," and available to every service that needs it.

    The control of the CIO over the contents of the corporate desktop will wane.  This trend has been going on for some time, and CIO magazine has not only recognized it, but recommended that CIOs embrace it. (See Users who know too much). It is time to let the users have the control.  The force is unstoppable anyway.  Initiatives and products that attempt to wrestle control back to the CIO will meet with success briefly, but will ultimately fail to gain foothold as the tidal wave of user-self-determination washes away these obstacles.

    Information will move to the 'cloud.'  There is no avoiding it.  The individual users who create distill information from data will control that information, often outside the boundaries of the corporate walls.  Secrets will become harder to keep, and IP will become even more difficult to control, even as IP becomes more valuable to the survival of the top corporations of the world. 

    Corporations will install their on local or proxied versions of popular Internet services in hopes of keeping intellectual property assets from leaking out.  In-hosted services, however, will fail to prevent the migration to the internet cloud, as partnerships and communities will increasingly extend well past the boundaries of the corporation.  As they do, the 'center of gravity' will shift away from the corporation to the community: an extended space defined by the people themselves, with their own rules for information management. 

    To cope, Corporations will purchase "spaces" in popular sites for members of their company to collaborate safely.  IT departments will begin to adopt common standards for protecting that data, and will push those standards on large service providers.  A new conversation will emerge, from the IT community that, in the past, drove very few standards.  So while corporate information will move out of IT, control over how it is managed will collectively shift.  Information will be assured and managed, not controlled. 

    All of this is driven by the net-top.  This is the new space, and Microsoft is coming.  We are creating products an increasing rate, moving resources, shifting priorities, reorganizing.  The movement is taking hold inside Microsoft, and that is an amazing thing to watch.  I was here when Microsoft "discovered" the Internet, and this time, there is even more seriousness than in the 90's.  Microsoft will not, cannot, has not, ignored the net-top. 

    Sure, folks like Salesforce and Amazon are already there, and winning customers with excellent products.  But we are there as well, and we are driving forward at an accelerating rate.  Competition is what drives us all.   No one loves to compete more than Microsoft. 

    And you can't count us out.  Not on something we are serious about.  A long time ago, Microsoft was not first in spreadsheets, but now Excel is the king of spreadsheets.  Once upon a time, Microsoft was not the first in presentation software, but now elementary school kids learn Powerpoint as an essential job skill.  I don't know the market share of Exchange or SQL Server, but I'm certain that we have gained, gradually, relentlessly, continuously. 

    We are serious about the net-top. 

    The battle has been joined. 

  • Inside Architecture

    Fitting SOA+BPM into the software lifecycle

    • 4 Comments

    I have a SOA view of the software development lifecycle.  And, in that SOA view, BPM fits nicely.

    First, a comparison: Waterfall looks like this:
    Waterfall: Plan --> Envision --> Design --> Develop & Test --> Deploy
    Agile: Plan --> Sprint --> Sprint --> (occasionally) Deploy --> Sprint --> Deploy

    A SOA SDLC looks more like this:

    Plan --> Sprint (Process and User Experience) --> Sprint (Process & Services) --> Deploy --> Sprint (P&UX) --> Sprint (P&S) --> Deploy

    In other words, you get as far as you can go with the user experience, you update the services, and you deploy.  Then, you do it again.  (I think Agile works a LOT better than waterfall).

    So what does a "Sprint (Process and User Experience)" do?  The dev team is focused ONLY on the front end.  No changes to the back end are allowed.  This is a feedback cycle, in that services are developed slowly and carefully, mostly with heavy unit test and runtime testing requirements.  During that time, there is less involvement with the customer's team.  So by cycling like this (assuming sprint length of between three weeks and five weeks), you can have greater feedback and user acceptance testing by consuming more of their time in U/X during 'high cycles' and let them do their 'day jobs' during service cycles. 

    During "Sprint (Process and Service)" cycles, the team focuses on meeting the string requirements for creating and consuming enterprise services.  Heavy unit tests.  Real-time test harnesses.  Synthetic Transactions.  Idempotent design.  Activity Monitoring.  Performance testing.  Reliability testing.  You get the picture.

    Both kinds of sprints: process changes are happening.  That is because it can take a LONG time to run through a User Acceptance test on a Process, get feedback, and incorporate it.  No good reason to create a 'low cycle' in that work.

    I'm assuming mature process management tools, of course.

     

  • Inside Architecture

    Get BPM into IT project funding

    • 4 Comments

    One challenge that we run into: having a software developer design the business process.  Now, that's no slam on software developers.  There are some very smart cookies out there writing software... but if you want to develop a business process, you need to make sure that the business likes the process before you write the code.

    I believe that the person who develops the business process has to be seperate from the person who writes the basic code.  SOA supports this idea.  In SOA, the compositon is where the business process lives.  The services don't care what order they are called in.

    So if the developer doesn't write the process... who does?  Is it the IT analyst?  Is it the IT project manager or IT solution owner?  Only if they are trained to create well-designed and efficient processes.  If they are not, then it's not much better than having the developer do it.

    Honestly, the benefits of shared processes in a company can be substantial.  Any process that does not differentiate the business in the marketplace should be considered as a candidate for sharing between lines of business... (as long as those lines of business already share data).  Sharing a process can provide real opportunities for reducing cost and improving efficiency.  Each unique process carries a cost... in training, in tools, in exception procedures...  The fewer, the better.

    However, IT projects often do not have Business Process Management figured in.  BPM must be part of the way in which the software is understood, described, and communicated.  If BPM is considered first, then SOA can produce the benefits we want it to produce.  If BPM is not considered first, then you are cutting off many of the benefits of SOA. 

    Don't undercut the value of SOA by failing to manage the processes in your enterprise.  It would be a crying shame if you did.

Page 1 of 2 (8 items) 12