There is a common sets of views that architects have to be able articulate, typically for different audiences, each of which describes the same solution but at a different level of detail. Anyone prescribing to be an architect should be able to clearly articulate these three common views, why they are necessary and how they link together, as there is a strong traceable model between them.

A while back I took a role in mentoring some less experienced architects with an aim to solidifying their architectural thinking and moving them out of a Business analysis and design way of thinking. As part of this in-house upskilling programme I started writing an example of the 'Conceptual-Logical-Physical' views and their relationship. Whilst researching it online I found the example below, from the Zachman site. This is a great example, and clearly shows why the three views exist, and how they convey the right level of information to the correct audience, allowing each role to perform in its own space with, aiming at the same solution, but not restricted by any of the other roles around them.

Conceptual, Logical, Physical architecture example

The "Owner":  CONCEPTUALLY .....   "I would like a pot of flowers in the center of my patio about 10 feet off the ground.  They would be purely for ascetic reasons, but I want the pot to be BIG and the flowers to be real."

The "Designer":  "Let me see now ... the physics of this situation would suggest that there are two LOGICAL alternatives ... either 1) you would have to have a pedestal about 10 feet high, the weight it would have to sustain is max of 100 pounds so if it was 10 square inches in area (cross-section) the material would have to hold 10 lbs per sq. inch.  You're second alternative 2) would be to hang it from something above the pot ... do you have a roof over the patio??  If not, that would mean we would have to construct a tripod to suspend the pot from the apex.  Do you care if you see the tripod? I recommend you go with the pedestal."

The "Builder:"  "The Architect is suggesting a pedestal that would be 10 feet high and sustain 10 pounds per square inch.  That Architect wouldn't recognize a lathe if he fell on one ... but here's what we could do ... we could PHYSICALLY build the thing in three pieces and then glue it together with superglue ... just in case, we could make flanges on the pieces so we could bolt the pieces together to make sure they don't come apart.  Your other alternative is to have it made in Japan and ship it in one piece and then we could install it by drilling a hole in the patio, sinking the base down 2 feet and filling in the hole with cement.

For full disclosure, I have republished this from the Zachman site, the original is here

In the last few weeks I've had many conversations with Architecture colleagues about the differences between Architecture and Design. These conversations don't typically start with this question, but more likely about the content of specific deliverables such as documents or strategy papers. Typically as an Architect you are required to deliver guidance on solutions as part of a project cycle, or as part of a larger overall programme. The point at which that guidance changes from 'Architecture' into 'Design' can be quite a contentious one.

For me, as an Architect, my responsibility is to guide the Strategy and direction of a project in terms of the technical aspects. I am effectively the technical manager, governing the direction that a project proceeds in. So how is that different from designing the solution yourself?

I like to think of Architecture as:

"Performing Governance and assurance around a solution to ensure that it aligns to Architectural principles, Strategic concerns and established patterns, in an elegant and cost effective way."

In plain English this is formulating which architectural principles are relevant and applicable, which patterns (in terms of both technical design patterns or business process patterns) are relevant and lastly whether there is an overarching strategy or strategies that drive the direction. It is effectively a set of rules, constraints and measures to guide the further direction of a solution (whether that is a project or a programme). It IS NOT the actual design of a solution but rather the instruction set that a design should use to build their design. When Architectural Governance kicks in and I review a designers design documentation, this is the rules set that I use to effectively 'mark their homework'.

Now, if we have defined the Architecture side of this argument, we should really do the same for the design side. This is a lot more real-world and far less abstract, normally because it is much easier to visualise than 'Architecture' is.

"Design is the process of collecting and placing business and technical building blocks to enable business capabilities."

Again, in real terms this means finding vendors, products and technical elements that fulfil as many of the identified requirements as possible, and arranging them in such a way as to enable an end to end business capability, usually by combining many simpler capabilities into a larger one.

Thinking of Architecture and design in this way makes it very easy to see where the boundary between these separate activities lays, which in turn means it becomes far simpler to see where any handover between resources should be, or where responsibility within a project lies. This sort of clarification also really helps to define the boundaries of an Architectural role, allowing them to focus on specific Architectural deliverables.

One thing that is often overlooked in a partner driven outsourcing operating model are the specific alignment of the goals between the parent business / IT owners and the outsource partners themselves.

In the working model where core IT resource is supported by partners, such as IBM, Accenture and HP there is a large focus on the integration and working practices of the multiple teams involved. Each partner brings its own working practices and nuances of design and Architecture. Overcoming or adapting to these working practices often takes centre stage as this can consume the most amount of time and effort.

One key element of the outsource partner model, that's often overlooked, is understanding the partners goals and managing the differences in alignment to yours.

Your IT / business goals may be very open to the organisation. You could be driving towards your business goals by following a set up principles like:

• 1. Create a generic IT capability to allow greater market flexibility and adaptiveness, responsiveness to change
• 2. Follow principles of re-use and optimisation where possible, efficient cost management and resource management
• 3. Strict governance to industry wide standards to such frameworks as TOGAF, eTom and SOA.

Just as examples. There are likely a lot more than these, all lined up to point at the company vision.

Let's take a look at a partners goals now, I'm sure they are aware of the industry frameworks listed above, but are they a goal? No, they aren't. They are a way of integrating with the parent company. If I, as a governing body in the parent company, dictate that HP have to follow eTom category modelling then they will, but not because it brings them any benefit but because there is little to no chance of getting through the owning companies governance process without it.

This is quite a basic example but the idea is fundamental. Examine your outsource partners motivations when you look at their output. Does their design or implementation meet your requirements or does it meet their resourcing targets? Does something really take that long to deliver or have design decisions been affected by the fact that August is a slow month and the partner needs to place more people?

This is particularly relevant when you may be working in a fixed pricing model. If a release phase has an allocation of N thousand days a simple increase of 20% design and implementation time across the board from a partner can drastically reduce the amount of functionality you will receive, and the amount of design they have to complete.

I've found that there are an amazing variety of reasons that designs are influenced, or potentially deviated from their 'ideal' state. Just make sure that the financial goals of your partners aren't the primary reason that your company is saddled with a bizarre technical workaround for years to come.