Share via

Successful enterprise systems that deliver Agility

  • Article

Another idea to improve system quality …

I’ve contributed to the delivery of several enterprise systems where many were delivered successfully and many were serious failures (and a whole lot that were challenged). By failed I mean that two or more of the following was true: not on-time, not on-budget and didn’t meet the customer expectations. Funny though, even the successful solutions didn’t make me feel I’ve accomplished what I was after. I found that the systems which needed a big overhaul or a complete rip-and-replace to undergo changes in the business or IT was very, very disappointing. Systems need to be resilient to change. So, I’ve since decided that my definition of a successful solution was wrong. My current thinking is that a ‘successful’ solution has the following criteria:

1. On-or-before time,

2. On-or-under budget,

3. Delight the customer and

4. Ensure high-quality solution.

I’d like to talk about point 4 “Ensure high-quality solution” above as it relates to delivering high-quality solutions in the enterprise space to contribute to a ‘successful’ solution to keepthis somewhat short. For those PjMs, PdMs, Test Leads, and IT execs out there wondering about the other components that contribute to a successful enterprise system such as Project Team Roles and Responsibilities, Process Models, Organizational Cultures, IT and Business Maturity Models, etc, I think that these are equally important and intertwined but Architecture is where I have experience and can talk to it.

The idea I’d like to run through is based on the following principles:

1. Build IT systems to meet business needs

2. IT systems must have a management lifecycle and be specialized

3. System Architecture must provide enough guidance to System Designers

4. Systems must be high quality

I’ll describe each principle below.

1. Build IT systems to meet business needs

Let me run through a very quick description for identifying business needs. Certainly, in the enterprise space ‘business needs’ are derived from business strategy. Business capabilities are built from business strategy and provide the means for quickly assessing where improvements are necessary to deliver on the business strategy. Through analysis of either a cursory assessment of the business capability model or through higher-accuracy analysis via capability and process measurements, one can identify where high-value business capabilities are underperforming. The next step is to focus efforts to improve these underperforming business capabilities via business process improvement activities, systems improvement initiatives, a repositioning the business capability or any combination of these. I don’t want to go into depth here but if you’re interested to find more on this, have a look at Gartner’s Business Architecture or Microsoft Business Architecture (MBSA) (formerly known as Microsoft Motion). Anyway, for the modeling geeks out there, I see the business capability models derived from MSBA as Viewpoints (IEEE Std 1471-2000) that include:

  • Stakeholders:
    • Senior business executives
    • Enterprise Architects
  • Concerns
    • What are the business capabilities which describe what is necessary to deliver on the business strategy?
    • What is the metadata for each business capability which inform correlated business process(es), information model(s) and application model(s)?
  • Models
    • Business Capability Heat maps
    • Business capability hierarchy with a multi-dimensional connectedness via attribution contained in generic ‘entities’. Entities, in this context, are essentially a generic UML Class definition which represent things which are connected to business capabilities. I see them as a great way to extend and introduce into the business capability model IT systems.
  • Patterns, References, etc
    • Referenced Industry Business Models

Ok, so how does Business Capability Architecture contribute to improving quality solutions? Two ways:

1. Stability through stable business capabilities. Because business capabilities represent stable logical groupings of business functions, systems that reflect the business capabilities tend to be more stable in their scope. That is, if systems are scoped by business capabilities, they are likely to require significant change as a result to business changes such as business process changes for example.

2. Flexibility through system decoupling. Applications automate business processes. Unfortunately, due to the nature of business processes being changed continuously, application system interfaces often become unusable over time. So, when designing application system interfaces, reflect the coupling nature of business capabilities. For example, if an application system interface is deemed appropriate to automate a business process and the business process is shared between two or more highly-decoupled business capabilities where one of them is considered low-value, then it might be likely that the low-value business capability may be repositioned elsewhere like outsourcing for example. If the system interface implements the Façade Object-oriented Design Pattern, therefore optimizing for system Flexibility, perhaps the system interface can endure the change in the business process or system integration as a result of outsourcing the business capability.

 

2. IT systems must have a management lifecycle and be specialized

Ok, now that we are confident we are building systems that are tied to stable business needs and gain the benefit of injecting system Flexibility based on the coupling and business value of business capabilities, we can now focus on how to structure enterprise systems and a bit of how to manage them. Before I jump in to this, you need to remember that in the enterprise space, one of the primary goals is to provide Agility. This is achieved with a combination of several factors such as a simplified IT environment and optimization of some specific system quality attributes such as System Agility. System Agility is the ability of a system to be both flexible and undergo change rapidly (defined by Tom Allen at MIT). System Agility is a system quality attribute that optimizes rapid delivery of solutions to the business. In my opinion, the most important factor to achieving system Agility is system Flexibility. System Flexibility is the ease with which a system or component can be modified for use in applications or environments other than those for which it was specifically designed (as defined by M. Barbacci at SEI). System Flexibility provides the ability for systems to better endure changes in the business such as business capabilities and business processes as well as changes in IT systems without one dramatically affecting the other. I wrote a piece regarding system Flexibility and you can read about it more to get details on this idea. This is all well and good for the average system, however in the enterprise space we need more. The enterprise space requires specialization. Sidebar, I think that SaaS will also demand specialization and I hope that the lessons learned from the enterprise space influence SaaS system architectures. Anyway, Enterprise systems need to be specialized into independent system platforms that embody a logical grouping of functionality to optimize support for core business processes and maximize the technologies which enable them. For example, specialized enterprise systems that reflect what I’m talking about are Incident Management, Product Lifecycle Management, Relationship Management, Contract Management, etc. In some of the Enterprise Architect circles, these large-scale enterprise systems are called Solution Domains. These Solution Domains require organizational capabilities to manage the system such as Release Management, Onboarding/Adoption Services, Core Business Process Management, Technology Platform Management, etc. For this reason, I think that without these organizational capabilities large scale enterprise systems become marginalized through misuse. Organizationally aligned, specialized enterprise platforms gives us major benefits such as:

  •  Large-scale productivity
  • Improved Agility
  • Sustain growing demand and growth
  • Improved business system quality
  • Large-scale system and business process reuse
  • Simplified IT environment

Essentially, the description of specialized systems is no different from the concepts described in Software Engineering Institute’s Software Product Lines or the awesome work from Jack Greenfield’s work on Software Factories that extend and make SEI’s SPLs tangible and ready for your everyday enterprise organization. If you subscribe to a centralized IT model which aims to provide reusable enterprise system assets across several lines of businesses, then Software Factories are a very intriguing proposition. I think that there is some unbelievable insight and thought put into Software Factories to address enterprise system challenges such as system segmentation, lifecycle management, system domain capability strategy, etc.

So, for those wondering how I see SOA as a part of enterprise systems, here’s a quick overview of the process steps I use.

  1. Target core, high-value business processes. To help identify high-value business processes, look at business processes which directly support a high-value business capability as well as ‘automate-able’ business processes which are very expensive. Look to tools from MSBA Business Capability Models in conjunction with Enterprise Business Architecture to quickly do this.
  2. Identify candidate business services that maximize business activity reuse by analyzing business processes, core entities, existing services/applications and an Architect’s experience. There are so many ways to derive application services that I tend to pull from all of them where appropriate. Craig McMurtry has recently endorsed Scenario-based Design process as described in Krzysztof Cwalina’s book ‘Framework Design Guidelines and feel that this is yet another method for identifying application services when in ‘green field’ scenario and think that this is a nice addition to add to the application services designer utility belt.
  3. Identify decoupling requirements via Business Capability Architecture. This step relates to what I wrote in section 1. Build IT systems to meet business needs under point #2 of the system quality benefits.
  4. Check to see if these business services exist in an existing Solution Domain and if so, look to reuse or extend that platform using the methodology of SEI’s Software Product Line and implement via Software Factories approach.
  5. If a service doesn’t exist, identify service granularity (Fine/Atomic or Course/Orchestrated). There are plenty of techniques out there to do this, I’m intrigued by the Service Granularity Analysis approach described in the book “Service Oriented Architecture: A Planning and Implementation Guide for Business and Technology”.
  6. Focus on the Course-grained candidate services and test them by running through this checklist:
  • Do they adhere to the SOA tenets?
  • Are they Durable? That is, are the application services mapped to business processes which are likely to be unchanged over time. This is often very hard to determine b/c as Six Sigma practitioners often remind us is that business process changes are triggered from the Voice of the Customer. So, predicting business process changes is tricky and speculative at best without empirical data in the form of business process metrics which support a recommendation for a change.
  • Are they Composable? That is, are the application services built for incremental consumption and functionality without breaking the contract with existing service consumers.
  • Are they business aligned? Stay away from, well at least initially, from focusing on technical services, data services, infrastructure services but rather focus on services which align to the business.
  • Are they Reusable? Design the services using reuse OO design patterns such as façade and adapter patterns.
  1. Once done, look to standard EAI Patterns and Enterprise Application Patterns to build the a system’s architecture from which include the application services defined from the above process.

BTW, on the topic of application services, another area of specialization is the management application services. Simply creating application services and hoping that the gravity of ‘mash-ups’ will enable enterprise systems and bring the benefits of Agility, you’re still learning. We need specialization targeting management of application services to enable application services in the enterprise space to host and manage application services. Think of it as a sort of runtime environment for hosting application services that provides functionality needed to manage application services in an enterprise (eg lot and lots of application services) scale. For example, the .Net Common Language Runtime (CLR) provides runtime functionality for all .net applications such as security, auditing, tracing, debug, etc. Rome provides runtime application service management functionality like service discovery, reliability, service registry, security, routing, etc. This is where project ROME fits into the story and we are all very interested in its results. J

 

3. System Architecture must provide enough guidance to System Designers.

This principle addresses the pains of ensuring alignment to a system architecture by system designers without ‘over architecting’ a system and end up forcing architecture and it being rejected or not used by system designers. There has been a lot of discussion around how much architecture is enough. I don’t want to go down that rat hole but I do want to talk about some basic fundamentals for striking that delicate balance. To be brief, System Architects should:

  • Describe the bounds of the system with which a system designer must design the rest of the solution. In many cases, this means describing the system endpoints, system partitions, and identification of other systems which must be reused.
  • Provide to system designers architectural and design patterns to use and where to use them in the system.
  • Provide design process guidance to help system designers design systems within the bounds of the architecture.
  • Ensure system quality. I’ll talk more about this in the next section…

So how does this contribute to system quality? Two ways:

1. Patterns or references to best practices to optimize system quality. System Architecture should identify patterns which optimize a set of prioritized system quality attributes such as Flexibility, Maintainability, Performance, etc. Here’s a blog entry tied to patterns which optimize system Flexibility if you want to know more.

2. Improves quality of System Design. I’m referring to the quality of the artifacts and if there is guidance for system designers to adhere to such as design process, modeling approach, modeling notation, artifact traceability and so on then the likelihood to improve system quality is higher. Here’s a blog entry tied to this if you want to know more.

4. Systems must be of high quality

One thing that I’m particularly passionate about these days is looking at ideas for raising system quality all in the name of trying to bring more value of our IT systems to the business. My assertion is that if systems are optimized for Flexibility, Maintainability, Testability, Reusability, Interoperability, Security, then it is more likely to be Agile and therefore be more resilient to business or IT changes as well as enabling faster time-to-market solutions. I’ve already written about ideas to improve system quality such as:

 

5. Assumptions:

Some assumptions which you should be already familiar with are:

  • Jack Greenfield’s Software Factories
  • Microsoft Business Architecture (aka MS Motion)
  • Microsoft Solutions Framework
  • Software Engineering Institute’s Software Product Lines product
  • System Quality Attributes and methods to implement and monitor them

 

6. Q&A

I know that some of you will be asking yourself questions about what I’m saying. We in Microsoft are critical in nature and in order to understand something we must test it by kicking the tires on it first. In anticipation of this and aid this process, I’ve created some Q&A.

1. How does SOA fit into all of this?

  • SOA provides a component of the overall strategy to make systems more relevant to the business. That is, build applications as services which can automate business processes. I’m not saying forget about all the other types of application services such as utility services, atomic services, meta-process services, etc. What I am saying is that the focus should first be on those services which bring direct connection to business processes. In the enterprise space, there is much more to the equation for delivering higher business value in our IT systems and application services which directly enable business processes so SOA as a primary element become relative to the other important factors becomes more of a component of the different bits of the four principles noted above.

 

7. Disclaimers:

1. I am a product of my environment and don’t pretend that any of what I’ve said is original. I have had the pleasure of working with gods in the industry such as entire Microsoft IT Enterprise Architecture team, James Simpson, Vajira Weerasekera, James Whittred, David Chandra and the entire Microsoft Business Architecture team under Ric Merrifield to only name a few. I am eternally grateful to have learned what I could during my short stints around them. Also I’ve pulled heavily from books written by Martin Fowler, Hohpe and Woolf, Paul Clements, Peter Weil, Jack Greenfield, Karl Wiegers, Krzysztof Cwalina, Eric Marks, Michael Turner, and others. I hope to at best plagiarize them and not to bastardize what they’ve come up with. By the way, if you feel that I’m restating something already said, no problem. I haven’t read all the material on or related to this subject so this can easily happen. If this has happened, consider what I’m saying as complimentary and like-minded.

2. If you feel I’m missing something, cool. Please add your comments as I’m just offering a place to start the conversation and am eager to discuss improvements.

3. If you feel I’m totally wrong, cool again. Let’s have a conversation.

Comments

  • Anonymous
    March 11, 2009
    My comments would be that it is nearly impossible to be totally correct in this space but overall many of the points you make are excellent. I have also been working in this space for a number of years and mame similar points often. We are in a middle ground right now where people are starting to see the benefits of moving towards an architecture driven approach, but it is more frustrating as they know its the right thing to do, but are still not doing it. Business Capability Modelling and a true understanding of SOA are very rare still in our industry. I think we are quite a few years away yet from this changing. Keep up the thinking, enjoyed the read.