Sunday, March 1, 2009

Architecture vs Design

The failure to be clear about what we mean by Architecture is associated with a failure to be clear about the design process.

One of the purposes of the strategy & architecture (S&A) is to assist us in supporting the design of business solutions i.e. specific solutions owned by the business that deliver value. The role played by the S&A is one of guiding and constraining the solution, the design process (i.e. the synthetic and creative process) and supporting the evaluation of alternatives (i.e. helping measure how optimal each solution is). In addition it should ideally be used as part of a formal authorisation process.

The design process

Design involves creating an optimised solution based on a set of constraints. When designing technology solutions (including selecting technology products and services) the constraints can be considered to be three major categories i.e. the problem domain, solution domain and strategic domain.

Problem Domain
The problem domain is usually defined by a business case related to the specific business project or owner. This set of constraints may be called the requirements. The business case will usually require a business owner focuses on achieving specific business outcomes. The typically technology solutions will be just one aspect the business owner is considering.

The business owner will usually make clear the desired: business outcome e.g. value creation (or improved outcome by some other measure), time to market etc.; business services or offerings to be provided, supported or enhanced i.e. both their nature and quality; business objects and processes to be supported, enhanced (e.g. automated, streamlined etc.), developed or maintained; business control and governance considerations to be met (e.g. security, regulatory, corporate); business community to serviced; business costs and how return will be achieved i.e. what investment can be made and how the investment can be justified

Solution domain
This relates to what can be created. Our knowledge of the solution domain is based largely on historical knowledge (what we have done, what we know works etc.), our circumstances and the environment (what is available to us) and includes: what we know about how solutions are constructed e.g. best practices, heuristics, patterns; the specific skills, techniques and technical knowledge we have about systems and their operation; the technical assets we have i.e. tools, technology infrastructures (systems, software, hardware), legacies (bespoke and purchased product) and services.

Strategic domain
We can consider a there to be third set of constraints that represents the broader business requirements (i.e. the requirements that represent the sum of all the current future business goals, strategies, projects, initiatives etc.) i.e. beyond the scope of the current project, and beyond the ambit of the immediate business owner. This is what the technology strategy and architecture represents. They can be considered to be in the problem domain (as they are a set of meta-requirements) and the solution domain (to be useful the meta-requirements are usually synthesised so they can be expressed as solution domain constrains). They include: themes and visions; structures and topologies (i.e. high level layout and design); common infrastructures, principles, standards, metrics; transition strategies (i.e. interdependencies roadmaps, constraints etc.).

Often an S&A is reflected in a set of principles that can be combined with other constraints to allow design. Usually some principles are more important to the stakeholder that others (weighting principles in an objective way is very complex and not dealt with in this discussion). In practice decisions are not always made simultaneously (i.e. some decisions precede others) and trhe order in which
decisions are made influence the design.

Getting back to the design process
The process of design can be considered to involve a number of activities (that are undertaken at many levels i.e. recursively, fractaly, iteratively or in parallel). At the highest level we can think of: determining the set of constraints (e.g. requirements gathering), creating a solution by synthesising all of the constraints and imaging possible solutions (design or selection) and evaluation. These steps as different in nature (but intimately connected) i.e.
- first – determine the constraints: is essentially objective (from the designers perspective) i.e. if the business person specifies a requirement it is taken as an objective fact by the designer. It may be a subjective assessment by the business owner providing the requirements i.e. it may, or may not have been objectively determined.
- middle – design synthesis: is non-procedural, inductive, one of synthesis, creative and requires imagination, demands a holistic focus, is intuitive and relies on experience etc. the result from this step is one or more design alternatives or scenarios.
- finally – evaluate design alternatives: involves measurement, assessment, is analytical and should be objective. At major design elaboration or decisions points it makes sense to have a structured and formalised approach. (e.g. our Solution Evaluation Model or SEM). This helps ensure objectivity, transparency and traceability i.e. it helps everyone understand why a design is preferred. This understanding in turn helps educate all parties regarding the implications of specific types of constraints or requirements.

Evaluating the alternatives
A designer may review the constraints and determine a solution they prefer (for what ever reason). Once one is attached to a design there is a tendency to want to move on quickly. While this will often be the correct, and only pragmatic, thing to do (as we rely on intuition, common sense etc.) when major decisions are involved good designers will confirm for themselves that the other alternatives are inferior of the design (or that other constraints that justify their preference need to be articulated).

Alternatively a business person may look at a solution (e.g. a product) and determine it best suits their needs (for what ever reason) i.e. is the optimal solution. Once one is attached to a solution there is also a tendency to want to move on quickly. Again this will often be the correct and pragmatic course of action. But when major decisions are involved most good business people will usually seek confirmation that other alternatives are in fact inferior.
Further items will discuss some of these things in more detail: problem domain, solution domain, principls, patterns (Patterns are generic models that allow one or more design point to be achieved), heuristics and best practices, solution evaluation models.

Considering the longer term
As we are dealing with systems that are undergoing constant change we need to understand why things exist and what problems would exist if we changed what exists. This implies we need an understanding of rationales. It is only by developing this understanding that we can learn, continue to improve the rate that we change and produce better results.

1 comment:

Anonymous said...

I like the valuable information you provide in your articles.
I'll bookmark your blog and check again here frequently.

I'm quite sure I'll learn many new stuff right here!

Best of luck for the next!

Here is my website architectural