Gabriel Morgan : System Quality

SaaS Service Offerings redefine what's in a product

Gabriel Morgan — Tue, 29 Jan 2008 11:01:00 GMT

As I continue my work on my little nook of Microsoft's S+S business strategy, the team I work with has noticed something peculiar about what exactly a Service Offering really is. Because we know the packaged software business so well, we sometimes overlook what at first seems like a subtle difference in the SaaS business but eventuates into something quite substantial. One such situations is the understanding of what a Service Offering is compared to a packaged software product.

Service Offerings via SaaS redefine what a product is

In the traditional packaged software business, product features define what a product is but Customer 2.0 expects to have direct access to operational features within the Service Offering itself.

Take for example Microsoft Word. Product Features such as Import/Export, Mail Merge, Rich Editing, HTML support, Charts and Graphs and Templates are the types of features that Customer 1.0 values most in a product. SaaS Products are much different because Customer 2.0 demands it. Not only must a product include traditional product features, it must also include operational features such as Configure Service, Manage Service SLA, Manage Add-On Features, Monitor Service Usage Statistics, Self-Service Incident Resolution as well. In traditional packaged software products, these features were either supported manually, didn't exist or were change requests to a supporting IT department.

Service Offering = (Product Features) + (Operational Features)

Operational features directly impact the most valuable aspect of the Software Service Provider business...service quality for customer retention. Dr. Nilesh Bhide, one of my esteemed colleagues wrote a great blog post on the value of the qualitative customer experience for a Service Provider business (see here). This is a fascinating reality online Service Provider businesses have.

So, what downstream impacts are there for SaaS products? There are two that I'd like to look at; operational business processes and their supporting business systems.

The operational business processes must now include Self-Service Incident Management and Self-Service Service Management to streamline and enable the direct interaction between Customer 2.0 and the Operational systems to make real-time incident resolution and service configuration changes on the fly. Inability to have these automated business systems result in a degradation of service quality and inevitably customer attrition.

Product Managers of SaaS Service Offerings must include into the Service Offering operational features to optimize customer retention. They cannot be an afterthought nor can they be lower in priority. They are a key 'feature' of the Service Offering itself.

This assumption implies that the systems providing the operational features must also have the highest system quality that product features have. System quality attributes such as system reliability, system security, system performance and system usability. Any downtime, lack of usability or any other poor experience with these features naturally reflect the rest of the Service Offering itself. This is the point I want to make with this article. Guess who builds and supports these Operational Features? Your friendly neighborhood IT department in conjunction with the Operations and Service Offering product group. This raises the quality bar for your traditional IT shop.

Oh, and by the way, these must be provided at a very low maintenance cost so as not to cut into the profit of the low profit-margin SaaS business. As noted in the Wall Street Journal the other day "Microsoft’s troubles in online services grew in the quarter as losses widened – to $245 million – due in part to increased costs of data centers..." ("Microsoft Net Surges With Help From Vista", Robert A. Guth, Wall Street Journal, Friday January 25, 2008). Of course, data center cost isn't the only factor to the $245 million dollar loss but it was a significant contributor. This is a sharp reminder that online Service Provider business must have efficient data center operations to be profitable.

The need to focus quality on the operational features to run a successful business isn't all that surprising. Geoffrey Moore once wrote "For core activities, the goal is to differentiate as much as possible on any variable that impacts customers' purchase decisions and to assign one's best resources to that challenge. By contrast, every other activity in the corporation is not core, it is context. And the winning approach to context tasks is not to differentiate but rather to execute them effectively and efficiently in as standardized a manner as possible." Business processes such as the customer-facing sales, fulfillment, assurance/support and billing are all core because they have direct interaction with the qualitative customer experience. Therefore, these processes become a top priority in order to be competitive in the online software service market. This understanding is a critical component for software service providers today.

The formula for Agility

Gabriel Morgan — Fri, 07 Sep 2007 04:59:00 GMT

Months ago I published a blog about how to implement system quality attributes (found here). In that article I asserted that Solution Architects should deliberately design systems for high quality and I provided a means for doing this. Because the point of software, or so I assert, is to automate business processes and protect data quality with the goal of enabling an Agile business, I'd like to propose a formula for determining System Agility.

So, how can we design systems to optimize System Agility in order to enable our agile business? Perhaps this isn't all that complicated if we use system quality attributes. Here's a stab at a formula for System Agility:

A=2(F)+M+I+T+R-P-S

The aim of this formula is not to pretend that one could use it to calculate System Agility with precision. Rather it is more of an attempt to describe how System Agility could be achieved. Using the formula allows me to describe the relationship of key system quality attributes that optimize and degrade System Agility and leave it to the Solution Architect to focus on the relative system quality attributes and implement systems design to optimize or minimize each of the key system quality attributes included in the formula.

Before I explain each factor, let me cover the assumptions I've made:

Agile businesses require Agile systems and the definition I use for System Agility is the ability of a system to be both flexible and undergo change rapidly [MIT ESD 2001].
The list of system quality attributes listed at the end of this blog under the label System Quality Attribute Definitions is the finite set of system quality attributes. Yes, I know that this is a false assumption but humor me for a moment.
I don't get into the complications of the natural system quality dependencies. That is, for the sake of this formula being very simple, I don't recognize the dependency tree of system quality attributes and their interrelationships and I let each system quality attribute stand on it's own.
For simplicity of my key messages in this blog, I focus on the software system only and don't address organizational capabilities nor infrastructure needed to properly deliver System Agility to an enterprise.

Let me take a moment and explain each factor in the equation.

(F) System Flexibility Factor. The most important system quality attribute to enable System Agility is System Flexibility. System Flexibility enables systems to be used in different ways and to be modified for these different uses. It is the means for decoupling interactions between actors. Targeting System Agility, System Flexibility allows software to be reused in ways not thought of at the time of development. I published a blog on System Flexibility, found here, that directly addresses ways to optimize System Flexibility at the enterprise-level. For this reason, I've assigned a multiplication factor to System Flexibility to emphasize the importance of System Flexibility to System Agility.

(M) System Maintainability Factor. System Maintainability is very important to agile software. The key here is code that is optimized for System Maintainability is more likely to withstand changes from bugs that are found and fixed or as well as software that undergoes natural improvements. Software characteristics that are directly pertinent to System Maintainability include; Versioning, Re-factored code, Code Complexity, code structure, etc.

(I) System Interoperability Factor. System Interoperability brings to the table a focus on interoperating between systems, which is arguable one of the most important concerns for enterprise applications system integration. Software characteristics that are directly pertinent to System Interoperability include; Service Operation designed for uniqueness and extensibility, Message Schemas including those that are canonical, software design patterns that optimize for composability to support orchestration and workflow.

(T) System Testability Factor. System Testability is important because it forces system designers to make deliberate system architecture decisions to ensure that the software that is produced can be easily tested for delivery. Especially as we see software designed from service-oriented software architecture approaches and S+S needs, the ability to design software to enable these types of software needs requires intentional design to optimize testability. Software characteristics that are directly pertinent to System Testability include; abilities to perform Unit Tests, Customer Tests, Stress Test, Exception Tests, Failover Tests, Function Tests, Security Penetration Tests, Performance Test, System Integration Tests, Regression Tests, Code Coverage Tests, etc.

(R) System Reusability Factor. System Reusability is an important system quality attribute involves major architectural styles and patterns like the Service Layer Pattern [Fowler 2003], basic software design principles such as software encapsulation and the familiar SOA Tenets.

(P) System Performance Factor. System Performance often degrades System Agility and for this reason I've asserted that System Performance subtracts from the previously noted system quality attribute factors. Bummer. I wish that we could have our cake and eat it too but the reality is that when optimizing for System Agility, System Performance is a Tradeoff Point. For example, often the fastest systems tend to consolidate large amounts of logic, data and processing instructions onto a single platform to reduce network latency, packaging and unpackaging of inter-process information, data access, etc. I don't want to ignore performance enhancing techniques such as caching and patterns such as Data Transfer Object [Fowler 2003]. These are great ways to lessen the impact that System Performance can place on System Agility. It's just that these add a bit of complexity to the rest of the system and can degrade System Maintainability and System Testability for example and still don't, from a purist perspective, optimize System Performance.

(S) System Security Factor. Like System Performance, System Security often degrades System Agility and for this reason I've asserted that System Security has a negative relationship to the equation. For example, Adding software characteristics such as role-based security into a system at the data layer, application layer, host layer and network layer adds significant degradation to System Performance, System Testability and System Maintainability. I'm not at all suggesting that a Solution Architect should read this as a suggestion to place little System Security design into their system. The trick, as a colleague once told me, is to have just enough security.

System Quality Attribute Definitions

Agility

Agility is the ability of a system to be both flexible and undergo change rapidly. (MIT ESD 2001)

Flexibility

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. (Barbacci 1995)

Maintainability

Maintainability is:

· The aptitude of a system to undergo repair and evolution. (Barbacci 2003)

· The ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment. (2) The ease with which a hardware system or component can be retained in, or restored to, a state in which it can perform its required functions. (IEEE Std. 610.12)

Interoperability

Interoperability is the ability of two or more systems or components to exchange information and to use the information that has been exchanged. (IEEE 1990)

Testability

Testability is the degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met (IEEE 1990).

Reusability

Reusability is the degree to which a software module or other work product can be used in more than one computing program or software system. (IEEE 1990).

This is typically in the form reusing software that is an encapsulated unit of functionality.

Performance

Performance is the responsiveness of the system – the time required to respond to stimuli (events) or the number of events processed in some interval of time. Performance qualities are often expressed by the number of transactions per unit time or by the amount of time it takes to complete a transaction with the system. (Bass 1998)

Security

Security is a measure of the system’s ability to resist unauthorized attempts at usage and denial of service while still providing its services to legitimate users. Security is categorized in terms of the types of threats that might be made to the system. (Bass 1998)

Reliability

Reliability is the ability of the system to keep operating over time. Reliability is usually measured by mean time to failure. (Bass 1998)

Supportability

Supportability is the ease with which a software system is operationally maintained.

Performance

Security

Scalability

Scalability is the ability to maintain or improve performance while system demand increases.

Usability

Usability is:

· The measure of a user’s ability to utilize a system effectively. (Clements 2002)

· The ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component. (IEEE Std. 610.12)

· A measure of how well users can take advantage of some system functionality. Usability is different from utility, a measure of whether that functionality does what is needed. (Barbacci 2003)

Sources

· [Bachmann 2000] Bachmann, F.; Bass, L.; Chastek, G.; Donohoe, P. & Peruzzi, F. The Architecture Based Design Method (CMU/SEI-2000-TR-001 ADA375851). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2000. Available WWW: <URL: http://www.sei.cmu.edu/publications/documents/00.reports/00tr001.html>.

· [Barbacci 1995] Barbacci, M.; Klien, M.; Longstaff, T; Weinstock, C. Quality Attributes - Technical Report CMU/SEI-95-TR-021 ESC-TR-95-021. Carnegie Mellon Software Engineering Institute, Pittsburgh, PA.

· [Barbacci 2003] Barbacci, M. Software Quality Attributes and Architecture Tradeoffs. Software Engineering Institute, Carnegie Mellon University. Pittsburgh, PA.

· [Bass 1998] Bass, L.; Clements, P.; & Kazman, R. Software Architecture in Practice. Reading, MA; Addison-Wesley.

· [Bass Kazmann 1999] Bass, L.; Clements, P.; & Kazman, R. Architecture-Based Development.

· [Fowler 2003] Martin Fowler. Patterns of Enterprise Application Architecture, Boston, MA. Addison-Wesley.

· [Gamma 1995] Gamma, E.; Helm, R; Johnson, R.; & Vlissides, J. Design Patterns, Elements of Reusable Object-Oriented Software. Addison-Wesley. Carnegie Mellon Software Engineering Institute

· [Hohpe Woolf 2004] Gregor Hohpe and Bobby Woolf. Enterprise Integration Patterns. Boston, MA. Addison-Wesley.

· [IEEE 1990] Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY.

· [IEEE 1992] IEEE Std 1061-1992: IEEE Standard for a Software Quality Metrics Methodology. Los Alamitos, CA: IEEE Computer Society Press.

· [Kazman 2000] Kazman, R.; Klein, M. & Clements, P. ATAM: Method for Architecture Evaluation CMU/SEI-2000-TR-004 ADA382629. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. Available WWW: <URL: http://www.sei.cmu.edu/publications/documents/00.reports/00tr004.html>

· [MIT ESD 2001] Tom Allen, Don McGowan, Joel Moses, Chris Magee, Dan Hastings, Fred Moavenzadeh, Seth Lloyd, Debbie Nightingale, John Little, Dan Roos, Dan Whitney. ESD Terms and Definitions (Version 12); Massachusetts Institute of Technology. Engineering Systems Division. ESD-WP-2002-01, October.

Implementing System Quality Attributes

Gabriel Morgan — Wed, 21 Mar 2007 02:19:00 GMT

I recently participated in an IASA initiative to document skills needed by Software Architects. I wrote an article on Implementing System Quality Attributes - see below.

Here's the location of the article on IASA: http://www.iasahome.org/c/portal/layout?p_l_id=PUB.1.269&p_p_id=20&p_p_action=1&p_p_state=exclusive&p_p_col_id=null&p_p_col_pos=3&p_p_col_count=4&_20_struts_action=%2Fdocument_library%2Fget_file&_20_folderId=61&_20_name=01-Implementing.pdf

Here's the location of the IASA initiative: http://www.iasahome.org/web/home/skillset

Here's the article on Skyscrapr: http://msdn2.microsoft.com/en-us/architecture/bb402962.aspx

What do you think?

Implementing System Quality Attributes

In this article I aim to describe how to implement system quality attributes in software solutions with the expected benefit of improving return on investment from IT systems

Gabriel Morgan

Implementing Quality Attributes

When I was a teenager my friend’s father gave him the family spare station wagon as his first car. It was an old, decrepit Ford LTD station wagon that wasn’t exactly the type of car one at our age would flaunt to attract the type of attention we were after. But it was the only car either of us had, so it was just fine…of course, once we could fix it up a bit that is. We decided to turn it into a something more to the aesthetics of a roadster by raising the rear wheels, replacing the carburetor with a set of after-market dual-carburetors, replacing the aged seats with 5-point harness racing bucket seats and giving it a new coat of paint.

During that experience, I remember leafing through loads of catalogs containing descriptions of parts from various after-market manufacturers which all matched the published Ford LTD station wagon specifications for the 454 Cleveland V8 engine, interior seat mounts and rear suspension brackets needed for the car’s conversion. We chose what we could afford and installed them ourselves following simple installation instructions. We didn’t need to rebuild anything, nor force-fit any of the parts, nor fabricate any custom mounts to reuse that old station wagon for our new purposes. At the time, this event meant nothing to me other than a bit of fun over a couple of weeks during our summer break.

Now, let me tell you a very different story surrounding a very similar event. I once delivered a software solution for a customer who was a market leader in the online retail industry focusing primarily on selling computer goods. The solution consisted of a set of systems which automated order acceptance through fulfillment business processes. The customer was thrilled the day the solution went into production as it meant to him that he could reduce the costs by automating much of the manual activities for these processes and direct his focus on empowering his marketing group.

Wahoo, drinks for everyone…until a couple of years later.

The industry became increasingly more competitive and in order to survive, my customer needed to diversify into several lines of retail goods, he needed to outsource billing services to lower costs, lower his prices by comparing multiple suppliers’ price offerings and improve customer satisfaction by committing to delivery dates by partnering with multiple shipping partners. He hoped to win new customers and to improve customer satisfaction. The systems I developed were not built to easily support this type of change in the business nor were they well designed to be compatible to the flurry of IT packages that hit the market which provided specialized components for system integration, customer care management, faster supplier enablement, marketing campaign management, etc. I ultimately had to redesign parts of the architecture. This took considerably more time than it would have taken if I had initially designed them for change in the first place. In the end, the systems required a major overhaul to meet the needs the business.

Let’s go back to my story of converting my friend’s station wagon and repurposing it for the needs of two teenagers versus my experience converting my customer’s online retail systems to support multi-store channels, multi-supplier relationships, and provide for more sophisticated functionality. The two experiences were conceptually similar in their scenario but far different in their execution. A few years ago I began to think about this and ask myself some questions. Would it have been possible for my original online retail systems to have been more resilient to change in the business processes as well as changes in IT technologies? Is it possible to design systems to become more resilient to change and improve the chances for not having to perform major overhauls? I believe it is.

I’m not suggesting we software architects are the sole contributor to reach the level of efficiency the automobile industry has today, as this takes experience, industrialization, collaboration between car manufacturers, healthy competitive market of part suppliers, adherence to automobile industry standards and quality control, which we in the software industry salivate for. What I am suggesting is that we should consider learning from the design concepts that make the automobile industry unbelievably successful and see how we go.

I propose that Solution Architects, in addition to contributing to the delivery of a working system to customers, are also responsible for ensuring system quality with the express intention of building systems to be resilient to change. In this article, I will describe an approach for building systems designed to sustain changes in business processes as well as changes in technology platforms for Solution Architects to leverage and reap the long-term benefits of improving customer’s return on investment.

Plan for implementing system quality

To implement system quality, it’s best to start with a plan. Software quality, by definition, is the degree to which software possesses a desired combination of attributes (IEEE 1992). Therefor, in order to improve system quality, we need to focus our attention on software quality attributes. Ultimately, there are only a few system quality attribute primitives that all system qualities can map to. In my experience I’m quite fond of the system quality attributes listed in Appendix A: System Quality Attributes which include Agility, Flexibility, Reusability, Performance, Security, etc. Note that these are by no means the definitive set of system quality attributes nor are the definitions the only acceptable definitions to consider. I’ve used these and have been relatively successful with them. The important thing to remember is to come up with a set so that you can clearly communicate with stakeholders the system quality impacts of your architecture decisions.

Back to my story regarding the station wagon conversion…I was pleased with the amount of effort it took to modify and extend the Ford LTD station wagon. The designers of the Ford LTD station wagon predicted that there would be a need for owners wanting to replace parts with after-market components and designed the car to be maintained, in my case upgraded, to be compatible with parts from other car part vendors.

There are a few system qualities that contributed to this positive experience such as Maintainability and Testability but there is one system quality which stands out – system Flexibility. The Ford LTD station wagon designers specifically implemented the Ford LTD design for Flexibility. Maybe not in these exact terms, but I do think they thought about making the design of the automobile to be composed of other automobile part manufacturers other than what Ford produced. Of course, the primary driver for the Ford designers to optimize for Flexibility was probably not for benefit of the after-market car part manufacturers but rather to give Ford the benefit of choosing from several bidding car part manufacturers and choose the right balance of quality and cost for their production model. As a consequence, car part manufacturers benefitted from after-market sales by providing upgrade replacement parts to the same flexible design specification.

Someone smart once stated "You can't manage what you can't measure", therefore you need to think about the measures of system quality to make sure you can plan how to go about monitoring them throughout the software lifecycle. You will need to plot out just what you will expect the system designers to build so that it is optimized for system quality. A good approach that you can leverage to plan how to implement system quality is the IEEE Software Quality Metrics Methodology (IEEE 1992). Basically, this methodology suggests following these steps to define and monitor system quality metrics:

1. Establish software quality requirements

2. Identify software quality metrics

3. Implement software quality metrics

4. Analyze results of these metrics, and finally

5. Validate the metrics

Prioritizing system quality attributes

The IEEE Software Quality Metrics Methodology (IEEE 1992) is more of a framework than a strict methodology. You need to add the details yourself to make it work.

First, prioritize the system quality attributes before spending time identifying software quality metrics so as to speed up this process. That is, what’s the point of spending time identifying software quality metrics for system quality attributes you are not going to monitor because they are deemed not a priority?

Second, don’t strictly follow the serial process regarding steps 4 and 5, “Analyzing results of the metrics” and “Validate the metrics” respectively. Because it is good practice to monitor for the existence of well-engineered system quality requirements as part of the overall solution requirements, it is a good idea to monitor for them. As Karl Wiegers notes “software quality attributes or quality factors, are part of the system’s nonfunctional (also called nonbehavioral) requirements.” (Wiegers 2003) The assumption here is that including system quality requirements into the solution’s project requirements improves the chances for a high-quality solution. For this reason, don’t assume that you have to complete each step before moving to the next and find yourself missing the boat on an opportunity to improve system quality. For example, you may just find yourself well into the design phase of your project by the time you get around to completing steps 1 through 3. As you monitor and analyze the metrics regarding system quality requirements, you recognize that you’re too late to go back and inject missing system quality requirements for the project and now you’re left with a bit more risk for a poor-quality solution being developed.

Now that you have a set of defined system quality attributes to draw upon, the next step is to prioritize them for your particular solution and think about how you will go about monitoring for them throughout the software development lifecycle with the aim of determining if system quality is being implemented.

Ideally, you would want to optimize for all quality attributes, but in fact this is nearly impossible because any given system has Tradeoff Points (Clements 2002) which prevent this. A Tradeoff Point is a property that affects one or more attributes. Essentially, changing one quality attribute often forces a change in another quality attribute…either positively or negatively. This is important because knowing the prioritized system quality attributes and their Tradeoff Points aids the decision-making process during design activities.

The graph below is taken from the book Software Requirements Second Edition (Wiegers 2003) and describes an example set of system quality attributes and their Tradeoff Points.

Availability

Efficiency

Flexibility

Integrity

Interoperability

Maintainability

Portability

Reliability

Reusability

Robustness

Testability

Usability

Availability

Efficiency

Flexibility

Integrity

Interoperability

Maintainability

Portability

Reliability

Reusability

Robustness

Testability

Usability

Table 1: System Quality Tradeoff Points

Here’s a quick example to illustrate Tradeoff Points. Let’s say that there is a need for a system service which aims to provide a means for processing banking transactions. The business has noted in the requirements that it must be fast. Assuming that the system designer has not read this article, she immediately begins to optimize the service for Performance. In this hypothetical case, the system designer might opt to build a high-performance application by building a system which

· Captures system requests directly from UDP communications port

· Uses proprietary message communication semantics

· Accepts system requests and processes application logic for system requests in a single process space.

· Embeds application logic in procedural code

· Persists data in local memory space for quick put/get operations.

· Sends responses to system calls in real-time to a high-performance receiving application preferably as close to the hardware level as possible using a proprietary binary communication transport.

Such a system has a number of Tradeoff Points. The three that stick out for me are:

· Interoperability. It will be difficult to interoperate due to the unstructured, unreliable UDP communication protocol as well as unsupported message formats not based on industry standards.

· Flexibility. The application’s decomposition doesn’t lend itself to be changed and reused for other purposes due to the proprietary protocols, coupled messaging and application logic as well as propriety memory store. The application also lacks application decomposition with encapsulated boundaries preventing the ability to plug other components into the system.

· Reliability. UDP communication packets are unreliable as packets could be lost, in-memory data is not persisted to disk and could be lost if the memory is released via a process fault, reboot, etc.

It may be that these sacrifices are intentional and accepted in order to achieve a high performance system…but maybe not. The business and IT owners may actually want the system to be flexible enough to withstand changes to the business processes it supports or technology changes that are inevitable. The point is that tradeoffs are made when optimizing system quality attributes and that if systems are designed with this understanding upfront, then there are less surprises down the road.

There are several processes which describe how to prioritize system quality attributes to derive system architecture such as Software Engineering Institutes (SEI) Attribute-Driven Design (Kazman 2000). In addition, there are some fairly well documented Tradeoff Points from SEI’s ArchitectureTradeoff Analysis Method (ATAM). ATAM is a very sophisticated method for determining Tradeoff Points through attribute characterizations which use the Stimuli-Architectural Decision-Responses construct (Kazman 2000).

ATAM is focused on the evaluation of software and includes in the method techniques for identifying and prioritizing system quality attributes. There are several other techniques/methods for identifying system quality Tradeoff Points in the industry. Which to use and how much to use from these industry practices depends on a number of things such as budget, resource competency, time to deliver, and solution size and complexity.

I often tend to simply adopt key concepts from these, infer from the solution requirements a set of likely important system quality attributes and collaborate with the key stakeholders to decide on three high-priority system quality attributes to focus the team on. So, my advice to you is to understand the approaches out there and weigh them for each solution to determine what’s best to include in your plan.

Monitor system quality attributes

We have defined a plan and are ready to define the metrics of system quality to monitor and track them throughout the software development lifecycle. The purpose of using metrics is to reduce subjectivity during monitoring activities and provide quantitative data for analysis.

So, what metrics should a Solution Architect inject into the solution to better address system quality? Any good system architecture has quality requirements, so this is a good place to start. To help explain let’s take a specific system quality attribute that I consider very important to deliver Agility to the business and IT stakeholders which is system Flexibility. Here are some Flexibility metrics to consider as an example of what to monitor for:

· Quality of Service (QoS) system requirements. The Solution Architect is responsible for the integrity of a solution and not having well-defined system requirements can lead to confusion downstream and eventuate in a poor quality solution. So, to mitigate this, ensure that system requirements include QoS requirements specifically for those which are correlated to the prioritized system quality attributes. Also, accompanying QoS requirements with Use Cases and Quality Scenarios (Bass Kazmann 1999) will further improve communicating the requirement to the project team and mitigate misinterpretation. For the purposes of the Flexibility example, here are two QoS examples:

1. “A business user who has at least six months of experience in the field shall be able to modify core business processes automated by the system without requiring a change in the system’s source code which, when done, these changes are placed into a queue to be tested, with no more than one hour of labor.” This requirement demonstrates the ability for the system to withstand changes in the business process.

2. “A software engineer can change, including effort to research, design, code, unit test and document, the Find Customer function in the solution to point from the current SAP CRM module to the Microsoft CRM provided Customer Search service interface and release the code changes to the testing environment within one day.” This requirement demonstrates the ability for the system to withstand changes IT systems.

· System patterns that improve quality. The Solution Architect should also identify system patterns which should be used to optimize for the prioritized set of system quality attributes. In my example of system Flexibility, patterns such as Façade (Gamma 1995), Adapter (Gamma 1995), Service Layer (Fowler 2003) and so on improve system Flexibility.

· System anti-patterns that degrade quality. Solution Architects should provide additional guidance on what system designers are to avoid and one method to do this is to identify the anti-patterns which negatively affect system quality. In my example of system Flexibility, anti-patterns such as Shared Database (Hohpe Woolf 2004) and Data Replication (Fuller Morgan 2006) degrade system Flexibility.

The point is that it’s up to the Solution Architect to identify metrics which are used to measure system quality. Unfortunately, no one has fully defined all measures based on scientific mathematics so this can be a challenge. Aim to define as much as you can, leverage existing metric definitions from industry practices as a starting point and build on it from your experience.

Once the system quality metrics are defined, embed them into the solution artifacts and monitor for their adoption througout the software lifecycle.Dduring the build and testing phases, review the system and find deviations from what you defined. These deviations should then be considered for correction.

Through implementing software quality into the solution using the approach described in this article, the solution is better positioned to not only give the business owner a quality solution but also improve its chances to withstand changes in the business and technology therefore maximizing the return on invesment.

Review

Let’s go through a quick summary of the three key points in this article. First, build high-quality software. While this may seem obvious I’m just pointing it out once again for the few who somehow could have missed it. J Second, understand that there are industry practices which guide Solution Architects to build high-quality software systems and they should be leveraged. And thirdly, you will need to build a plan for implementing system quality into your solution and to avoid optimizing for all quality attributes as this is nearly impossible to do. Instead, prioritize them and take the top 3 quality attributes and focus your attention on them. Ideally, if you succeed, you will have improved the chances that your software will last longer and reap the long-term benefits of improving the customer’s return on investment.

Critical Thinking Questions

1. What are the most significant system quality attributes which contribute to Agility and how would you weight them?

2. Beside Quality of Service requirements, design patterns and anti-patterns, what other measurable metrics could you monitor to track system quality?

3. What other methods beyond giving guidance to system designers could you employ to improve system quality? That is, are there methods that other team members could adopt as their responsibility to improve system quality?

Appendix A: System Quality Attributes

Quality Attribute	Definition
Agility	Agility is the ability of a system to be both flexible and undergo change rapidly. (MIT ESD 2001)
Flexibility	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. (Barbacci 1995)
Interoperability	Interoperability is the ability of two or more systems or components to exchange information and to use the information that has been exchanged. (IEEE 1990)
Maintainability	Maintainability is: · The aptitude of a system to undergo repair and evolution. (Barbacci 2003) · The ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment. (2) The ease with which a hardware system or component can be retained in, or restored to, a state in which it can perform its required functions. (IEEE Std. 610.12)
Reliability	Reliability is the ability of the system to keep operating over time. Reliability is usually measured by mean time to failure. (Bass 1998)
Reusability	Reusability is the degree to which a software module or other work product can be used in more than one computing program or software system. (IEEE 1990). This is typically in the form reusing software that is an encapsulated unit of functionality.
Supportability	Supportability is the ease with which a software system is operationally maintained.
Performance	Performance is the responsiveness of the system – the time required to respond to stimuli (events) or the number of events processed in some interval of time. Performance qualities are often expressed by the number of transactions per unit time or by the amount of time it takes to complete a transaction with the system. (Bass 1998)
Security	Security is a measure of the system’s ability to resist unauthorized attempts at usage and denial of service while still providing its services to legitimate users. Security is categorized in terms of the types of threats that might be made to the system. (Bass 1998)
Scalability	Scalability is the ability to maintain or improve performance while system demand increases.
Testability	Testability is the degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met (IEEE 1990).
Usability	Usability is: · The measure of a user’s ability to utilize a system effectively. (Clements 2002) · The ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component. (IEEE Std. 610.12) · A measure of how well users can take advantage of some system functionality. Usability is different from utility, a measure of whether that functionality does what is needed. (Barbacci 2003)

Sources

· [Barbacci 2003] Barbacci, M. Software Quality Attributes and Architecture Tradeoffs. Software Engineering Institute, Carnegie Mellon University. Pittsburgh, PA.

· [Bass 1998] Bass, L.; Clements, P.; & Kazman, R. Software Architecture in Practice. Reading, MA; Addison-Wesley.

· [Bass Kazmann 1999] Bass, L.; Clements, P.; & Kazman, R. Architecture-Based Development.

· [Fowler 2003] Martin Fowler. Patterns of Enterprise Application Architecture, Boston, MA. Addison-Wesley.

· [Fuller Morgan 2006] Tom Fuller, Shawn Morgan. Data Replication as an Enterprise SOA Antipattern. The Architecture Journal Issue 8. Microsoft Corporation. <URL: http://architecturejournal.net/2006/issue8/F4_Data/default.aspx>

· [Gamma 1995] Gamma, E.; Helm, R; Johnson, R.; & Vlissides, J. Design Patterns, Elements of Reusable Object-Oriented Software. Addison-Wesley. Carnegie Mellon Software Engineering Institute

· [Hohpe Woolf 2004] Gregor Hohpe and Bobby Woolf. Enterprise Integration Patterns. Boston, MA. Addison-Wesley.

· [IEEE 1990] Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY.

· [IEEE 1992] IEEE Std 1061-1992: IEEE Standard for a Software Quality Metrics Methodology. Los Alamitos, CA: IEEE Computer Society Press.

· [Wiegers 2003] Karl Wiegers. Software Requirements Second Edition; One Microsoft Way, Redmond, WA; Microsoft Press.

About The Author

Gabriel Morgan has over 10 years developing software and is currently an Enterprise Application Architect on Microsoft IT’s Enterprise Architecture team. He has extensive experience in the design, development and implementation of distributed software systems and experience solving enterprise application problems such as flexibility, performance and scalability. He has a patent-pending process and tool for performing system quality reviews called the Microsoft System Review. His current interests lie in deriving system architecture from business strategy.

Successful enterprise systems that deliver Agility

Gabriel Morgan — Fri, 03 Nov 2006 02:16:00 GMT

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:

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.

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.
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.
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.
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.
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”.
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.

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.

System Design Process thought...

Gabriel Morgan — Thu, 12 Oct 2006 22:50:00 GMT

I wanted to follow up a note I mentioned in a previous blog I wrote on how to Manage System Quality and talk about System Design Process as it relates to managing system quality. I’ve come across several methodologies that include system design processes like Rational Unified Process, Prince2, Method1, MSF, etc as well as several methods or techniques for system modeling like Model Driven Design/Development, Attribute Driven Development ADD, Pattern-Driven Analysis and Design (PDA) method, etc. I’m a fan of IEEE’s Views and Viewpoints and SEI’s ADD and thought that these two components combined can form a simplified process and short set of principles that can be reused consistently across any methodology. ADD provides the process for designing software and and Viewpoints provide a method for documenting them. For large projects that often require executing several software development methodologies (eg RUP, Method1, ADM, etc) a consistent process for documenting system architecture and design is very powerful.

Of course, I’m missing the need to have system templates and meta-model for connecting Viewpoints and if you have something to share regarding these, I’d love to see them.

· For those of you not familiar with Views and Viewpoints, the IEEE Std 1471-2000 is the recommended practice addresses the activities of the creation, analysis, and sustainment of architectures of software-intensive systems, and the recording of such architectures in terms of architectural descriptions. A conceptual framework for architectural description is established. The content of an architectural description is defined. Annexes provide the rationale for key concepts and terminology, the relationships to other standards, and examples of usage.

· For those of you not familiar with SEI’s ADD, The ADD method is a systematic approach to designing the architecture for a family of systems. It is based on knowing both the functional and quality requirements of systems and knowing the architectural approaches that have proven successful in other systems.

· For those of you not familiar with the system quality attributes, the Microsoft System Review has a single set of system quality attributes with industry definitions and references.

ADD provides the process for designing a software solution and Viewpoints provide a method of documenting them.

· Step 1. Identify prioritized system quality attributes

· Step 2. Identify architecture and design patterns to optimize high priority system quality attribute(s)

· Step 3. Create a Viewpoint

Modeling Process Details

This section goes one step deeper into describing the modeling process steps described above.

Step 1. Identify prioritized system quality attributes

There are many system quality attributes to choose from. Most of them force tradeoffs for others. The purpose of this step is to recognize which system quality attributes are of the highest concern and understand system quality attributes are sacrificed as a result. Knowing this aids the decision-making process during design activities.

For example, if the system requires optimizing a solution for Performance, then often, Flexibility and Interoperability are sacrificed. As a hypothetical case, a system designer might opt to build a high-performance application by implementing an application which

· Captures system requests from a thin hardware-level listening interface application from a UDP communications port

· Processes system requests in a single process space optimizing the platform’s execution designed to execute processing architecture.

· Application logic is stored and access a proprietary memory stored in-process and in proprietary format for quick put/retrieval operations.

· Sends responses in real-time to a high-performance receiving application preferably at the hardware level using a proprietary binary communication format.

Such a system has the following tradeoffs:

· Interoperability. It will be difficult to interop due to the unstructured, unreliable UDP communication protocol, unsupported message formats based on industry standards, etc

· Flexibility. The application’s decomposition doesn’t lend itself to be changed and reused for other purposes due to the proprietary protocols, message and memory design as well as the lack of application composition.

It may be that these sacrifices are intentional and accepted in order to achieve a high performance system. The point is that tradeoffs are made when optimizing system quality attributes and that if systems are designed with this understanding upfront, then there are less surprises down the road.

The result of this step is to identify a prioritized list of system quality attributes the system should be optimized for such as:

1. Flexibility

2. Maintainability

3. Usability

Step 2. Identify architecture and design patterns to optimize high priority system quality attribute(s)

Once the system quality attributes are identified and prioritized, identify architecture and design patterns to optimize for them. The aim here is to reference proven ‘best practices’ to help describe how the system should be implemented that target the system quality attributes identified in Step 1 above.

Taking the above prioritized system quality attribute list (Flexibility, Maintainability and Usability), the table below is a list of architecture patterns segmented by well-documented Architecture, Design and Styles that optimize system Flexibility.

Pattern Type	Pattern Name	Reference
Architecture	Functional Integration	http://msdn.microsoft.com/practices/topics/patterns/default.aspx?pull=/library/en-us/dnpag/html/archfunctionalintegration.asp
Architecture	Service Layer	http://www.martinfowler.com/eaaCatalog/serviceLayer.html
Architecture	Service-oriented Integration	http://msdn.microsoft.com/practices/topics/patterns/default.aspx?pull=/library/en-us/dnpag/html/archserviceorientedintegration.asp
Design	Adapter	http://www.dofactory.com/Patterns/PatternAdapter.aspx
Design	Event Message	http://www.enterpriseintegrationpatterns.com/EventMessage.html
Design	Façade	http://www.dofactory.com/Patterns/PatternFacade.aspx
Style	Messaging	http://www.enterpriseintegrationpatterns.com/Messaging.html

Table 1: Flexibility Optimized Patterns

Step 3. Create a Viewpoint

The Viewpoint is derived from the IEEE Std 1471-2000 concept of Viewpoint. For the purpose of this document, it’s important to follow this simple process to build the Viewpoint.

· Step 1 Title. Create the Viewpoint Title. Keep it simple with only a few words that have direct meaning to the those in senior positions.

· Step 2 Description. Describe the purpose of the Viewpoint and what it is contained in it.

· Step 3 Stakeholders. List the intended audience members of the Viewpoint.

· Step 4 Concerns. For each Stakeholder, list the questions, issues, concerns they have which the Viewpoint is intended to address.

· Step 5 Models/Diagrams. Build models using a common modeling notation to illustrate answers to the Concerns of the Stakeholders. UML provides a common models and model notation such as Sequence Diagrams, Activity Diagrams, Use Case Diagrams, etc but use whatever you feel is appropriate (DSL?) but make sure that whatever you use you describe in text it’s definition.

· Step 6 Relationship to other artifacts. Every model must have a relationship to another model. Ensure that the model has a connection with another model and describe that connection. Often a reference to a metamodel describing all model relationships for a given View.

· Step 7 Principles, Patterns and Guidelines. Include a listing of what principles, patterns and guidelines are used to build the model. For example, a logical architecture model can be annotated with tags where architecture or design patterns are used such as Services Layer, Messaging, etc.

Just a note on Service-oriented Architecture because it is such an important part of modeling. Here is a process I’ve come up with to address designing for SOA.

For service-oriented architecture (SOA) situations, here’s a bit of guidance for designing services in a SOA. It is by no means comprehensive but rather a high-level set of steps to help guide Service designs.

1. Target core, high value business processes.

· Business Strategy, Business Capability Architecture and Business Process Architecture drive this activity

· MS Motion is being adopted for Business Capability Architecture and used for identifying high-priority, high-value and core business needs

2. Identify candidate business services that maximize business activity reuse by using SOA design approaches such as:

· Analyzing business processes. Analyze business processes and search for opportunities where a Services could be used to easily automate them.

· Core entities. Analyze business entities that could be reused by multiple business processes and leverage object-oriented design techniques to transform entities into objects then wrap them with operations (aka methods) for simple reuse by the business processes.

· Existing services/applications. If part of the solution has existing applications, analyze the existing applications usage patterns and consider building Service Interfaces for operations of the existing applications.

· An Architect’s experience. Often an architect’s experience simply screams for the need of Services that don’t naturally drop out from the techniques above. Examples include an architect’s experience in a specific business domain and clearly sees a need for Application Services to simplify the solution and promote business process reusability. Don’t underestimate an architect’s experience.

3. Identify decoupling requirements via Business Capability Architecture.

4. Check to see if these business services exist in an existing Solution Domain. This step is to simply look around for existing application services within the same Solution Domain. If a service doesn’t already exist, identify service granularity (Fine/Atomic or Course/Orchestrated).

5. Focus on the Course-grained candidate services and test them for potential Service candidates by running through this checklist:

· Do they adhere to the SOA tenets?

· Are they Durable? Services that are mapped to lasting business processes.

· Are they Composable? Services are 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.

6. Once done, look to standard EAI Patterns, Enterprise Application Patterns, Object Oriented Design Patterns, etc to build the SOA architecture from.

· In particular, SOA drives system Flexibility. For this reason, leverage existing, proven, referenced patterns to optimize for system Flexibility such as those in Table 1 : Flexibility Optimized Patterns of this document.

System Quality Attribute Plan

Gabriel Morgan — Tue, 03 Oct 2006 23:54:00 GMT

There are several things that architects do when building and delivering solutions but one of the core responsibilities often seems to get lost early in the project lifecycle - ensuring system quality. For this reason, I thought it'd be interesting to talk about how this should be done to bring system quality back to the forefront of an architect’s thinking. Here are a few ways in which an architect can address system quality:

Building system quality processes into the solution design processes,
Building architectures that optimize system quality that are then consumed by system designers,
Establishing responsibilities for system quality on risk management teams,
Including system quality issues in issue tracking management,
Including system qualities into a solutions requirements

All of these are warranted in my mind and demonstrate comprehensive thinking of nifty techniques for improving system quality. One thing that seems to be missing here which is an area I've been recently thinking of is managing system quality. Someone smart once stated "You can't manage what you can't measure". I've experimented with measuring system quality for a couple of years now and think that there is great benefit for building high-quality systems but unfortunately isn't currently well exploited in the architect community. The ability to measure system quality, at least theoretically, provides the ability to help predict the lifespan of systems once released into production. This goes beyond traditional testing of systems. That is, testing systems today usually involves functional, security (or penetration), failover, integration, code coverage, etc testing. This helps ensure that the system will function once released into production. What's missing here is some level of assurance that the system will survive business or IT changes. I assert that if a system design optimizes system qualities such as Flexibility, Reusability, Testability, Maintainability, Interoperability, et al that it can withstand changes better and therefore has a longer lifespan and therefore potential greater ROI.

Software Engineering Institute's Atrribute Tradeoff Analysis Method (ATAM) is a great idea for understanding the tradeoffs for system quality. I once worked with a couple of sharp individuals to create a simplified method of measuring system quality called Microsoft System Review (MSSR). Although both are useful and successful in their usage they both require a bit more to provide the necessary process and tools for an architect to manage system quality. For this reason, I've been thinking of an approach which I've called System Quality Attribute Plan. I don't know if this name will stick...my idea is in the really, really early development stages. Anyway, SQAP has a few components:

SQA Target Capture which is a method for capturing the target measurements an architect expects the system to achieve
ADD Framework which is a simplified design process derived from SEI's Attribute Driven Design, Pattern-Driven Analysis and Design and a dash of some of my ideas. The point of the ADD Framework is to provide a design process driven by system quality.
SQA Review which is the process for measuring a system's quality and tracking the results which is largely the Microsoft System Review (MSSR).

SQAP is a rough approach at taking a stab at measuring system quality. It is not baked but more of an idea of mine. What is yours?

Design for Flexibility

Gabriel Morgan — Tue, 03 Oct 2006 23:42:00 GMT

First of all, let’s level set on the definition of system Flexibility. I quite like M. Barbacci’s definition which is “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.”

The beauty of this system quality attribute is that it is a key factor in providing Agility ("The ability of a system to be both flexible and undergo change rapidly" --MIT). In fact, I’ll blog some ideas I’ve been thinking as a formula for Agility because I feel Flexibility doesn’t seem to get the credit it deserves here…anyway, for arguments sake, let’s just assume that Flexibility is an important system quality attribute.

The problem I’d like to raise for discussion is how to help system designers build systems that are optimized for Flexibility. One approach I've been thinking about to help system designers build systems that are optimized for system Flexibility is to create an Architecture Principle which includes direction and explanation so that it can easily be consumed by system designers. I’d like to throw one out to this Architect Community to see what you all think.

The approach I’ve taken is

1. Identify well-known patterns that optimize for Flexibility in high and low level system abstraction levels.

2. Identify common scenarios in my IT environment and use them to explain what to do in those scenarios to optimize for Flexibility

3. Identify Flexibility anti-patterns, or patterns which degrade system Flexibility.

Using this approach this, I’ve created a document which contains the content of this design principle. Below is a first go at this principle:

Design for Flexibility

Description: 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.

Rationale:

Optimizing for system Agility is a primary goal for enterprise systems with the purpose of enabling rapid delivery of enterprise applications to the business. There are several system quality attributes which are used to calculate system Agility such as Reusability, Interoperability and Flexibility. Within Microsoft IT’s enterprise application environment, system Flexibility is of particular importance as it is a key factor contributing to an agile architecture. For this reason, attention is paid to ensure guidance is provided to system designers to ensure systems are optimized for Flexibility.

Implications:

If systems are designed to optimize system Flexibility, the expected benefits are:

· Enabling business process changes with minimum effect on technology platforms.

· Enabling technology platform changes with minimum effect on business processes.

· Enabling Service Oriented Architecture (SOA).

· Enabling modularized systems library for rapid system reuse.

· Improving system Maintainability.

A note about when and where to optimize for Flexibility: This sections includes a few scenarios commonly observed in Microsoft IT to help guide system designers where and how to optimize for Flexibility.

1. System Integration. There are three primary Interface Types to send and receive data between systems and they are; Real-time Integration, Near Real-time Integration and Batch Integration. Each of these scenarios are explained in the sections below.

a. Real-time Integration

i. The table below describes the scenario when Real-time Integration is often the best choice:

Term	Value
Transaction Volume – Traffic	Greater than 1 Peak Transactions Per Second
Transaction Volume – Message Size	Less than 10Mb Peak Message Size per Transaction
Interface Response Time	Less than 5 seconds
Latency Tolerance	Less than 5 seconds
Data State Staleness	Less than 60 seconds

ii. The table below lists patterns and styles which optimize systems for Flexibility for Real-time Integration scenarios. See Appendix A - Pattern Reference for details on these patterns.

Name

Adapter

Chain of Responsibility

Command

Data Transfer Object

Entity Aggregation

Event Message

Event-Driven Consumer

Façade

Functional Integration

Gateway

Message Broker

Message Bus

Message Endpoint

Messaging

Messaging Gateway

Observer

Pub/Sub

Remote Façade

Service Layer

Service-oriented Integration

b. Near Real-time Integration

i. The table below describes the scenario when Real-time ETL is often the best choice:

Term	Value
Transaction Volume – Traffic	Less than 1 Transactions Per Second at Peak period and greater than 1 Transaction per 30 minutes at Trough period
Transaction Volume – Message Size	Greater than 10Mb and less than 30 Mb Peak Message Size per Transaction
Interface Response Time	Greater than 5 seconds and less than 3 minutes
Latency Tolerance	Greater than 5 seconds and less than 30 minutes
Data State Staleness	Less than 30 minutes

i. The table below lists patterns and styles which optimize systems for Flexibility in Near Real-time Integration scenarios. See Appendix A - Pattern Reference for details on these patterns.

Name

Adapter

Chain of Responsibility

Command

Data Transfer Object

Entity Aggregation

Event Message

Event-Driven Consumer

Façade

Functional Integration

Gateway

Message Broker

Message Bus

Message Endpoint

Messaging

Messaging Gateway

Observer

Pub/Sub

Remote Façade

Service Layer

Service-oriented Integration

c. Batch Integration (aka ETL)

i. The table below describes the scenario when Batch Integration via ETL is often the best choice:

Term	Value
Transaction Volume – Traffic	Less than 10 Transactions per day at Peak period
Transaction Volume – Message Size	Greater than 30 Mb Peak Message Size per Transaction
Interface Response Time	Greater than 3 minutes
Latency Tolerance	Greater than 30 minutes
Data State Staleness	Greater than 30 minutes

ii. To optimize Flexibility in Batch Integration scenarios,

1. Use the following Object-oriented Design patterns; Façade and Adapter even within SQL Stored Procedures. See Appendix A - Pattern Reference for details on these patterns.

Name

Adapter

Façade

2. Follow guidelines to implement the concepts of encapsulation and ‘separation of concerns’.

d. SAP Web Services. This scenario is when an application requires integration to an SAP BAPI which is wrapped with a Web Service application. To optimize for Flexibility, the Web Services which directly wraps the SAP BAPI should implement the following Object-oriented Design patterns; Façade, Canonical Data Model and Adapter. See Appendix A - Pattern Reference for details on these patterns.

2. Configuration Management scenarios. Systems which have been designed to optimize for Flexibility take advantage of configuration mechanisms allowing for changes to the behavior of an application via changes in a system configuration file.

a. Types of Configuration Management changes that optimize for Flexibility are

i. Configurable Logging sources and log message types

ii. Configurable modules for in-process interception – Note that the Chain of Command Object-oriented Design pattern should be used in these situations.

Measure:

· é Green – The use of Architecture patterns which optimize Flexibility are used at all architecture and design abstraction levels as well as an implementation of Configuration Management for all major non-functional and functional sub-systems and system components.

o Examples of proven Architecture Styles and Architecture and Design patterns which optimize system Flexibility are in the table below. See Appendix A - Pattern Reference for details on these patterns.

Name

Adapter

Chain of Responsibility

Command

Data Transfer Object

Entity Aggregation

Event Message

Event-Driven Consumer

Façade

Functional Integration

Gateway

Message Broker

Message Bus

Message Endpoint

Messaging

Messaging Gateway

Observer

Pub/Sub

Remote Façade

Service Layer

Service-oriented Integration

o Types of Configuration Management changes that optimize for Flexibility are

§ Configurable Logging sources and log message types

§ Configurable modules for use process interception – Note that the Chain of Command Object-oriented Design pattern should be used in these situations.

Separation

· è Yellow – Architecture patterns which optimize Flexibility at the design abstraction level. Examples of such design-level patterns which optimize system Flexibility are:

Name

Adapter

Chain of Responsibility

Command

Data Transfer Object

Entity Aggregation

Event Message

Event-Driven Consumer

Façade

Message Endpoint

Observer

Remote Façade

Note: See Appendix A - Pattern Reference for details on these patterns.

· ê Red – System implementations which:

o Do not implement any of the styles and patterns listed in Appendix A - Pattern Reference with a Direct or Indirect value in the “Relevance to Flexibility” column.

o Are using patterns such as

§ Shared Database

§ Remote Procedure Invocation

o Do not follow guidelines for Encapsulation and Separation of Concerns

o Do not have configurable sub-systems or application components.

o Implement a Batch Integration system integration type for a Real-time or Near real-time scenario

1.1 Appendix A - Pattern Reference

Name

Relevance to Flexibility

Type

Reference

Remote Procedure Invocation

Anti-pattern

Style

http://www.enterpriseintegrationpatterns.com/EncapsulatedSynchronousIntegration.html

Shared Database

Anti-pattern

Style

http://www.enterpriseintegrationpatterns.com/SharedDataBaseIntegration.html

Adapter

Direct

Design

http://www.dofactory.com/Patterns/PatternAdapter.aspx

Event Message

Direct

Design

http://www.enterpriseintegrationpatterns.com/EventMessage.html

Façade

Direct

Design

http://www.dofactory.com/Patterns/PatternFacade.aspx

Functional Integration

Direct

Architecture

http://msdn.microsoft.com/practices/topics/patterns/default.aspx?pull=/library/en-us/dnpag/html/archfunctionalintegration.asp

Messaging

Direct

Style

http://www.enterpriseintegrationpatterns.com/Messaging.html

Service Layer

Direct

Architecture

http://www.martinfowler.com/eaaCatalog/serviceLayer.html

Service-oriented Integration

Direct

Architecture

http://msdn.microsoft.com/practices/topics/patterns/default.aspx?pull=/library/en-us/dnpag/html/archserviceorientedintegration.asp

Chain of Responsibility

Indirect

Design

http://www.dofactory.com/Patterns/PatternChain.aspx

Command

Indirect

Design

http://www.dofactory.com/Patterns/PatternCommand.aspx

Data Transfer Object

Indirect

Design

http://www.martinfowler.com/eaaCatalog/dataTransferObject.html

Entity Aggregation

Indirect

Architecture

http://msdn.microsoft.com/practices/topics/patterns/default.aspx?pull=/library/en-us/dnpag/html/archentityaggregation.asp

Event-Driven Consumer

Indirect

Architecture

http://www.enterpriseintegrationpatterns.com/EventDrivenConsumer.html

Gateway

Indirect

Architecture

¡ http://msdn.microsoft.com/practices/topics/patterns/default.aspx?pull=/library/en-us/dnpag/html/desgateway.asp

¡ http://www.martinfowler.com/eaaCatalog/gateway.html

Message Broker

Indirect

Architecture

¡ http://msdn.microsoft.com/practices/topics/patterns/default.aspx?pull=/library/en-us/dnpag/html/archmessagebroker.asp

¡ http://www.enterpriseintegrationpatterns.com/MessageBroker.html

Message Bus

Indirect

Architecture

http://msdn.microsoft.com/practices/topics/patterns/default.aspx?pull=/library/en-us/dnpag/html/archmessagebus.asp

Message Endpoint

Indirect

Architecture

http://www.enterpriseintegrationpatterns.com/MessageEndpoint.html

Messaging Gateway

Indirect

Architecture

http://www.enterpriseintegrationpatterns.com/MessagingGateway.html

Observer

Indirect

Design

¡ http://msdn.microsoft.com/practices/topics/patterns/default.aspx?pull=/library/en-us/dnpatterns/html/DesObserver.asp

¡ http://www.dofactory.com/Patterns/PatternObserver.aspx

Pub/Sub

Indirect

Architecture

¡ http://msdn.microsoft.com/practices/topics/patterns/default.aspx?pull=/library/en-us/dnpag/html/despublishsubscribe.asp

¡ http://www.enterpriseintegrationpatterns.com/PublishSubscribeChannel.html

Remote Façade

Indirect

Design

http://www.martinfowler.com/eaaCatalog/remoteFacade.html

Appendix A Glossary

Term

Definition

Agility

Ability of a system to be both flexible and undergo change rapidly.

Architecture Pattern

An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.

Architecture Style

An architectural approach to solving a common problem.

Business Capability

The unit describing the combination of people, business process and technology and the policy around its management

Component

Defined as executable/source code, practices, patterns, services as prescribed by Technical Architecture team.

Data State Staleness

The difference between the master state, from which the cached state was created, and the current version of the cached state.

Design Pattern

A design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonly recurring structure of communicating components that solves a general design problem within a particular context.

Encapsulation

Encapsulation conceals the exact details of how a particular class works from objects that use its code or send messages to it. So, for example, the Dogs class has a bark() method. The code for the bark() method defines exactly how a bark happens (e.g., by inhaling() and then exhaling(), at a particular pitch and volume). Timmy, Lassie's friend, however, does not need to know exactly how she barks. Encapsulation is achieved by specifying which classes may use the members of an object. The result is that each object exposes to any class a certain interface — those members accessible to that class. For example, an interface can ensure that puppies can only be added to an object of the class Dog by code in that class. Members are often specified as public, protected and private, determining whether they are available to all classes, sub-classes or only the defining class. Some languages go further: Java uses the protected keyword to restrict access also to classes in the same package, C# and VB.NET reserve some members to classes in the same assembly using keywords internal (C#) or Friend (VB.NET), and Eiffel allows one to specify which classes may access any member

Enterprise Solution

Any system that participates in an end to end business process that spans beyond the organization. The solution is SAP, Siebel, Clarify,/Metropolis, *ebis, or a solution that masters a key data entity such as Organization, Partner, Customer, Solution Opportunity, Campaign, Product or Order (among others).

Extract Transform and Load (ETL)

Extract Transform and Load is an approach to create nearly-identical copies of the data and to manage the integrity of the copies if they can be updated at both the source and target within a replication interval.

·         http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns/html/ArcDataReplication.asp

Flexibility

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.

Implementation Pattern

An implementation pattern is a low-level pattern specific to a particular platform. An implementation pattern describes how to implement particular aspects of components or the relationships between them, using the features of a given platform.

Intentional Integration

Defining a public data and service contract to the process and data owned by a system. Should not be consumer driven decision

Interface Response Time

Amount of time a consumer application is expected to wait for a response from the provider application.

Interoperability

the ability of two or more systems or components to exchange information and to use the information that has been exchanged.

Latency Tolerance

Delay between updates between the Source Application and the Destination Application. Some forms of data integration imply a delay between updates to the data that is used by multiple applications. For example, in the Data Replication pattern, the data is extracted from the source system, and it is transported over a network. The data might then be modified, and then it is inserted in a target database. This delay means that one system may have access to data that is more up to date than another system

Maintainability

Maintainability is:

·         The aptitude of a system to undergo repair and evolution.

·         The ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment. (2) The ease with which a hardware system or component can be retained in, or restored to, a state in which it can perform its required functions.

Near Real-time Integration

General term for describing asynchronous inter-system communication typically an implementation of the Message Bus Integration Style.

·         http://www.enterpriseintegrationpatterns.com/ComposedMessagingMSMQ.html

·         http://msdn.microsoft.com/practices/topics/patterns/default.aspx?pull=/library/en-us/dnpag/html/archmessagebus.asp

Performance

Performance is the responsiveness of the system – the time required to respond to stimuli (events) or the number of events processed in some interval of time. Performance qualities are often expressed by the number of transactions per unit time or by the amount of time it takes to complete a transaction with the system.

Process

A process is the business process that an application may be involved in executing or automating

Real-time Integration

General term for describing synchronous inter-system communication typically an implementation of the Request-Reply pattern. Note that Real-Time Integration can also implement asynchronous communication but in a fashion to scale synchronous communication.

Relevance to Flexibility

§ Direct. The pattern/style directly contributes to optimizing system Flexibility.

§ Indirect. The pattern/style indirectly contributes to optimizing system Flexibility.

§ Anti-pattern. The use of the pattern adversely affects system Flexibility.

Reliability

Reliability is the ability of the system to keep operating over time. Reliability is usually measured by mean time to failure.

Reusability

Reusability is the degree to which a software module or other work product can be used in more than one computing program or software system.

This is typically in the form reusing software that is a encapsulated unit of functionality.

Role

A collection of responsibilities and motivations, to which authorizations are attached.

Scalability

Scalability is the ability to maintain or improve performance while system demand increases.

Security

Security is a measure of the system’s ability to resist unauthorized attempts at usage and denial of service while still providing its services to legitimate users. Security is categorized in terms of the types of threats that might be made to the system.

Separation of Concerns

Separation of concerns is the process of breaking a program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors

Supportability

Supportability is the ease with which a software system is operationally maintained.

Testability

Testability is the degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met.

Transaction Volume – Peak Message Size

The largest message size expressed in bytes for a single transaction.

Transaction Volume – Peak Traffic

The largest number of transactions expected to be processed expressed in ‘transactions per second’.

Type

§ Architecture. See Architecture Pattern.

§ Design. See Design Pattern.

§ Style. See Architecture Style.

Usability

Usability is:

§ The measure of a user’s ability to utilize a system effectively.

§ The ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component.

§ A measure of how well users can take advantage of some system functionality. Usability is different from utility, a measure of whether that functionality does what is needed.

What do you think?

How do you provide Architecture/Design guidance to optimize for system Flexibility?

Name	Relevance to Flexibility	Type	Reference
Remote Procedure Invocation	Anti-pattern	Style	http://www.enterpriseintegrationpatterns.com/EncapsulatedSynchronousIntegration.html
Shared Database	Anti-pattern	Style	http://www.enterpriseintegrationpatterns.com/SharedDataBaseIntegration.html
Adapter	Direct	Design	http://www.dofactory.com/Patterns/PatternAdapter.aspx
Event Message	Direct	Design	http://www.enterpriseintegrationpatterns.com/EventMessage.html
Façade	Direct	Design	http://www.dofactory.com/Patterns/PatternFacade.aspx
Functional Integration	Direct	Architecture	http://msdn.microsoft.com/practices/topics/patterns/default.aspx?pull=/library/en-us/dnpag/html/archfunctionalintegration.asp
Messaging	Direct	Style	http://www.enterpriseintegrationpatterns.com/Messaging.html
Service Layer	Direct	Architecture	http://www.martinfowler.com/eaaCatalog/serviceLayer.html
Service-oriented Integration	Direct	Architecture	http://msdn.microsoft.com/practices/topics/patterns/default.aspx?pull=/library/en-us/dnpag/html/archserviceorientedintegration.asp
Chain of Responsibility	Indirect	Design	http://www.dofactory.com/Patterns/PatternChain.aspx
Command	Indirect	Design	http://www.dofactory.com/Patterns/PatternCommand.aspx
Data Transfer Object	Indirect	Design	http://www.martinfowler.com/eaaCatalog/dataTransferObject.html
Entity Aggregation	Indirect	Architecture	http://msdn.microsoft.com/practices/topics/patterns/default.aspx?pull=/library/en-us/dnpag/html/archentityaggregation.asp
Event-Driven Consumer	Indirect	Architecture	http://www.enterpriseintegrationpatterns.com/EventDrivenConsumer.html
Gateway	Indirect	Architecture	¡ http://msdn.microsoft.com/practices/topics/patterns/default.aspx?pull=/library/en-us/dnpag/html/desgateway.asp ¡ http://www.martinfowler.com/eaaCatalog/gateway.html
Message Broker	Indirect	Architecture	¡ http://msdn.microsoft.com/practices/topics/patterns/default.aspx?pull=/library/en-us/dnpag/html/archmessagebroker.asp ¡ http://www.enterpriseintegrationpatterns.com/MessageBroker.html
Message Bus	Indirect	Architecture	http://msdn.microsoft.com/practices/topics/patterns/default.aspx?pull=/library/en-us/dnpag/html/archmessagebus.asp
Message Endpoint	Indirect	Architecture	http://www.enterpriseintegrationpatterns.com/MessageEndpoint.html
Messaging Gateway	Indirect	Architecture	http://www.enterpriseintegrationpatterns.com/MessagingGateway.html
Observer	Indirect	Design	¡ http://msdn.microsoft.com/practices/topics/patterns/default.aspx?pull=/library/en-us/dnpatterns/html/DesObserver.asp ¡ http://www.dofactory.com/Patterns/PatternObserver.aspx
Pub/Sub	Indirect	Architecture	¡ http://msdn.microsoft.com/practices/topics/patterns/default.aspx?pull=/library/en-us/dnpag/html/despublishsubscribe.asp ¡ http://www.enterpriseintegrationpatterns.com/PublishSubscribeChannel.html
Remote Façade	Indirect	Design	http://www.martinfowler.com/eaaCatalog/remoteFacade.html