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 keep this 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:
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:
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.
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:
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:
Some assumptions which you should be already familiar with are:
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?
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.
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.