System Design Process thought...

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.

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.

Comments

• Anonymous
  May 29, 2009
  PingBack from http://paidsurveyshub.info/story.php?title=gabriel-morgan-system-design-process-thought