New architects often have a theoretical understanding of what an architecture should be, but are often left struggling with the level of detail required in their designs, frequently mixing physical solution with concepts. This frustrates stakeholders who are beginning to get their own visions of the solution. A few weeks later, and the purpose of the architect and his/her architecture is lost as the solution is being defined by everyone but the architect. It's not on purpose!

For example:

A new project is started, and everyone just knows that there are going to be some new IT systems.

In fact, everyone just knows it’s going to be a sales support solution, with a CRM installation of ‘product X’, that it’ll connect to existing customer databases Y and Z, and will produce regular management reports in exported spreadsheets.

Great – let’s just do it! That new architect on the third floor can be assigned – just brief him on our agreed solution.

Sounds familiar? And it just doesn’t feel right, does it! Why? Because it hasn’t taken a diligent approach to determining the right solution.

How do we know that the investment that will be made is going to capitalise on available opportunity? Is the person who just dictated the solution the right authority? How does this align to the business and IT strategies? Does this ‘pragmatic’ approach align well with other initiatives in the business?

In short, we don’t know if this approach and sketchy solution is on purpose.

To get to a solution that is on purpose, there are three stages of evolution that the architecture must go through, each with a distinct purpose of its own:

• Conceptual solution – defines the agree scope of the required solution, based on the high-level needs of the solution's identified stakeholders
• Logical solution – identifies and evaluates the feasible solution options that correspond to functional requirements within the defined scope
• Physical solution – specifies the physical solution of the options selected, in the context of the existing IT estate, and within the agreed scope.

Although there’s nothing particularly new about this concept, an ‘on purpose’ approach is rarely adopted, often with stakeholders, project managers and engineers jumping to physical solution mode before agreeing the scope and options for the change. The result? The architect on the third floor has few options and is forced into a technical documenter and fixer mode, eroding the potential value that a purposeful approach to architecture would have for the business.

The outlined 'on purpose' approach can be adopted into any framework – waterfall, iterative, etc. – helping the architect determine the level of detail required at each point of decision making through the stages of architecture evolution.

Stay on purpose and you will produced an architecture on purpose.

In a later publications I’ll argue that there are different ‘primary’ stakeholders for the purpose of each respective stage.

Three basic disciplines mirror the recognisable roles for IT projects: management, analysis, and architecture.  Each discipline overlaps to produce recognisable outputs (see illustration below), and, ultimately, the acceptable solution (delivery), where all three disciplines overlap.

The blend of disciplines within a project team affect its outcome:

• Analyse answers 'Why', on its own producing well-defined business needs and features wish-list – the other disciplines will govern this by defining scope and determining feasible solution options
• Architect answers 'What', on its own producing solution options and design specifications – the other disciplines will anchor designs in required solutions and implementation plans
• Manage answers 'How', on its own producing delivery plans (risk, time, budget) and resource allocation – the other disciplines will stretch this to establish scope based on need and plan based on design.

By recognising the business goals of the project early, blending the right mix of disciplines in the project leadership will improve the likelihood of achieving them. For example:

• Scoping exercise – the analyst takes the lead here, governed by the management role to ensure some boundary is defined; the architect is consulted only to ensure there is a good chance a feasible solution option may be found
• Feasibility study – the architect takes the lead, with the 'Analyse' discipline providing some context and 'Manage' ensuring there is some recognition of delivery planning
• Delivery project – all three disciplines work together, with clear responsibilities assigned to each resource; team members who have worked together before are more effective since each will understand the personality strengths of the other and may.

These concepts are nothing new, especially to those with IT project experience, but a goals-discipline focus is rarely a conscious part of the project resourcing process.

To take advantage of individual personalities and discipline focus:

1. Identify the goals of the project first
2. Determine the ideal mix of disciplines to achieve the goals
3. Assess and select the available resources that most closely resemble the team mix (sometimes one individual may cover more than one discipline)
4. Establish protocols and standards that will help govern any gaps in the project make-up.

This forces project business goals to be defined before the project team has been assembled and then it is the goals that influences the project team make-up.

Projects are comprised of humans – make sure the right people with the most appropriate disciplines are involved to give the project a better chance of achieving its goals.

In my last post (What’s the gap?) I observed that, for the most part, there is fairly good alignment between Business and IT. This is supported by research by McKinsey & Co showing that collaboration and business strategy alignment features strongly in the development of IT strategy for a large proportion of companies surveyed.

Also, the strategic importance of IT for Business is recognised by the high level of representation at the Board (44% of CIOs consulted by McKinsey in 2007 reported directly to the CEO).

The same report also highlighted that IT was heavily focused on managing and operating as a business service and this probably seems a natural role for IT.

Although there’s no doubt operating for service excellence is a key responsibility, sticking to this status quo contradicts a key factor of IT’s meteoric success over the last forty years. Had not the pioneers of modern IT innovated solutions to improve the accurate and reproducible management of information, businesses would now require impossible levels of resources to support their daily operations (imagine the number of filing clerks needed to man the vaults of index cards and paperwork to support today’s large insurance broker). In fact, without the Information Age modern businesses would not be able to support their modern day scale.

But innovation remains a neglected duty, with the majority of IT assessing themselves as not excelling. Of those interviewed by McKinsey, 57% indicated that they were either moderately or not at all effective at finding ways for IT to add value to their businesses (in other words, a failure to innovate based on internal needs). The picture was worse for innovation to improve competitiveness, where 67% of respondents were either moderately or not at all effective at introducing technology better than their business’ competition.

By settling into a routine of design, build and operate, IT is often failing to proactively point the direction to opportunity for Business to exploit … opportunities that business people have no way of understanding or detecting on their own.

IT leadership must grow to the next level of maturity, adding innovation as a core process to their lifecycle management, becoming as routine as specifying, building and operating a new server rack. This can be achieved by adopting key steps as part of the CIO role.

1. Establish your Enterprise Architecture (not new … but, really, have you defined your enterprise architecture current and target states? do you have a roadmap agreed by all stakeholders?)
2. Investigate your environment to improve competitiveness (do you research, subscribe to credible news feeds, have someone appointed to monitor key technologies and trends, have even a sketchy map of your technology landscape, regularly monitor the technology of your business’ competitors, and regularly evaluate the landscape against your business strategy to identify new opportunities?)
3. Liaise with your business’ IT users to spot opportunities for effectiveness and efficiency (pretty self-explanatory … but it is time-consuming … maybe innovate a way to make it easier to get feedback? what’s your immediate reaction when you do get feedback? … if it’s more "they just doesn’t understand IT", maybe you need to adjust your attitude, rather than the audience, to avoid missing opportunities)
4. Continually refresh the IT strategy and target EA (are you working with the business to ensure linkage of IT and business strategy change? does your EA reflect your IT strategy and vice versa? does your ‘current state’ EA truly reflect the current state and do you have a process for updating it with routine changes? is there a process for influencing business strategy based on the findings from environment and internal needs analysis?)

Adding these steps to your CIO office / IT department’s routine procedures in a way that naturally integrates with the rest of the way things are done (design, build, operate) will add innovation as an integral part of daily life. As this begins to produce real business benefits, the ordinary will become extraordinary.

I suggest that whatever gap there has been is pretty much on par with any other business discipline and the rest of the ‘Business’. How often have you heard line managers sighing "human resources" when they have been requested to tighten up performance review processes, or there has been disparaging comments about "bean counters" when finance has introduced a new set of controls.

I believe the Business / IT gap is actually a group-thinking contrivance nurtured within the IT fraternity and happily capitalised on by industry suppliers to develop cross-industry camaraderie and a sense of "we understand your pai". It’s a familiar topic that we can all nod together with some common understanding and feel bonded on a mission to change the world.

Yes, there was a gap when IT was a purely technical discipline before the evolution over the last 30 years towards an integrated business service. But that gap is now much smaller than it was in the 80’s thanks to a conscientious effort of our cross-industry discipline to deliver value to our businesses. The frustration we in IT feel from other areas of the Business isn’t a symptom of a growing gap, it’s a consequence of the increased importance of IT to the Business as a whole.

It’s now time for IT to cease its apologetics and get on with the business of being part of the Business.

What do you think? Are we ready to be part of the Business or have we got some more growing up to do?

But initiating an expansive governance programme with complex processes, detailed templates and a new organisation also can be counter-productive. The negative consequences could include lengthy delivery of the desired results, box-ticking for technical compliance but not producing what the business needs, and the development of antagonism between the governors and the governed.

This approach seems rather heavy-handed where, for the most part, non-compliance is the result of either doing the easiest thing at the time or a lack of awareness that the decisions being made contradict an established standard or policy.

Rather, any organisation with an enterprise architecture must develop a culture of consistent compliance through increased awareness and convenience of exercise.

Most compliant behaviour results from convenience and awareness, but focus on convenience

Discounting deliberate non-compliance as a contributor, there are two primary dimensions that drive compliant behaviour:

• Convenience of doing the right thing; if it’s easy to do, then your constituents are more likely to comply with the rules
• Awareness of what the right thing is; if you don’t know the rules, then only common sense prevails and technical decision-making isn’t always (rarely?) common sense.

The diagram illustrates the combination of these two dimensions to produce four general scenarios.

Chaos results from high barriers to compliance and low levels of awareness of rules & standards, as ignorant decision-makers choose the path of least resistance to achieve tactical outcomes.

Frustrated Disorder results when decision-makers are aware of the right way of doing things, but are faced with high barriers to achieving compliance; people are forced to knowingly do the wrong things as their decision making is channelled away from compliance.

Accidental Compliance is a state resulting from the condition where the barriers to compliance are low, making it easier to naturally do the right thing, but there is general ignorance of the rules; here, the right thing is done by default but, typically, inconsistently.

Deliberate Order is the Nirvana state, where compliance is as convenient, if not more, than doing the wrong thing and awareness of the rules is high; the right decisions are facilitated by reinforcing environmental conditions and an informed constituent acts as agents for compliance, with consistent and repeatable results.

Note that this model suggests that making people aware of the rules and guidelines without providing the facility to comply with relative ease will only result in a frustrated and disillusioned constituency. Surprisingly, many governance implementations feature a detailed communication of the rules and new processes that often disregard the current way of doing things. Perhaps this explains the poor reputation that architecture governance has earned – all it takes is one poor experience for a frustrated architect to tell his / her colleagues, fellow professionals and future employers, emulating the reputation network effect for marketing – it’s harder to go from good to great than to tumble down the league.

Haste and forced urgency results in inconsistency and tends compliance outcome toward chaos

We know the scenario all too well. A dictum from above increases the urgency for a project and applying normal procedures to ensure the outcome is compliant are now viewed as an impedement to the business. "Treat this one as an exception …" is the direction and the governance processes are circumvented. This signals a convenient alternative to other project managers who are always pressed to find faster ways of delivering. Before you know it, this ‘exception’ is being accepted as a norm, devaluing the enterprise architecture and, by ironic extension, resulting in a general failure to enable the business strategy.

Therefore, it is essential that any governance solution includes a defined ‘exception’ process that provides a convenient but procedural means of ensuring the same compliant outcome as for any other project. This would be achieved with an effective prioritisation framework that may accelerated the pace of decision-making for urgent projects, but in relation to the other priorities for the enterprise.

Develop a culture of acceptable behaviour to strengthen compliance

Communicate your enterprise architecture vision to every constituent group, ensuring that the message and benefits are relevant to each audience. Without a common vision that corresponds to the role of each member, the message will be lost and individuals will work towards their own interests and not that of the common good.

Once the common vision (and common good) has been articulated and accepted, then it will be easier to allow the natural social pressures of acceptable behaviour to help add weight to compliant behaviour. For example, specifying a new COTS solution application that has not been included on the EA roadmap for a project solution would result in a loss of reputation for the solution architect at the next architecture review board – not a good look. This pressure will also encourage architects to ask questions from domain engineers to ensure that their designs are compliant, improving collaboration and demolishing those ivory walls.

Clearly, architectures and technical designs that are discordant with the enterprise architecture will produce consequences felt at the business management level. Establishing a culture for compliance across the organisation will ensure that non-compliance will be unacceptable at ever level – it will no longer be non-compliance within IT, it will be non-compliance with the business as a whole, raising the stakes for anyone bold enough to defy the EA.

Conclusion – make convenience for compliance a priority and reinforce compliant behaviours with a postive culture

• Make it convenient to do the right thing first, then improve awareness of the rules to drive compliant behaviour
• Ensure urgent ‘exceptions’ don’t derail your governance initiative by establishing a process for managing exceptions in a prioritisation framework
• Develop a strong culture of acceptability and make everyone a stakeholder in the outcome, encouraging the connection with business enablement.

Common sense, isn’t it?

NB., this replaces an earlier article ‘Understand why governance is needed before deciding on how to govern’

Wikipedia eloquently describes ‘Architecture’ as the marriage between the art & science of designing physical structures. When confronted by well-designed architecture, one detects the sophistication & quality of design through all senses … it isn’t judged purely on the function of the structure. 

This careful attention to the completeness of design is rarely encountered in information and technical systems architecture. Why? Well, the common failures may be analysed by dissecting three simple points of balance:

• Design vs. engineering; because solution architecture is typically a function of IT, the tendency is to hire technical engineers as solution architects; design, as a qualification & outlook, is ignored and it shows in the product – the engineering of the technology may be excellent, but there is a lack of coherency in the wholeness of the product and absence of the characteristics of design
• Experience vs. function; too often time, budget, skill of the architect, and a focus on function results in a solution architecture that incompletely (if at all) addresses the experience aspect of architecture – it’s functionally complete, but it simply doesn’t feel right!
• Myopia vs. vision; without vision and imagination, the architecture will focus on the immediate context of the problem, relying solely on the conditions brought to the attention of the ‘designer’, without the stimulation of creative insight and innovation – it does what was asked explicitly, but ignores what was implied or needed.

Architecture is a creative science (yes, those words can be used together!). The distinction between engineering & architecture must be recognised in information technology and business systems design so that the right people are employed to produce architectural designs that are complete in both function and aesthetics.

Dedicate time & effort toward making a design product feel right, and the audience will applaud the result as well as appreciate its function. Apple have demonstrated this very effectively with products that not only function well but, more importantly, feel beautiful. The response from the market qualifies this approach. In fact, it seems that experience has been more important than function, since there are many available competing products that are functionally superior … they just don’t have that, well, "je ne c’est quoi".

But actually we do know what – don’t we?

Consider how often you have read an architectural design and, although technically good, you intuitively knew that something was missing.

Now gauge the number of times you read a design that was technically sound and felt it was comprehensive & inspiring.

If your experiences are anything like mine, then the cases of the former outweighed the latter, which inevitably leads to lengthy clarification workshops, issues during implementation as design assumptions are flushed out, and a large volume of high severity faults during testing.

So how can the balance be tipped in favour of good design to limit these potential issues? The answer is notionally simple: test the output of architecture against the recognisable, principle qualities of architectural design before proceeding to engineering and implementation stages.

There are seven principle qualities of technical design that, although individually distinguishable, together characterise comprehensive & balanced architecture:

• Cohesion
• Completeness
• Elegance
• Equivalence
• Hierarchy
• Modularity
• Vision.

These don’t define how to achieve an architectural design, but they do describe what architecture output feels like (architecture vs. specification vs. shambolic nonsense).

Cohesion

The action or fact of forming a unified whole.

The independent elements of the architecture function in harmony to fulfil a clear, common purpose; no element is left ‘orphaned’ from the rest of the architecture. The whole is an orchestration of the parts.

Cohesion runs within functional sub-components of an architecture (e.g., how related the functions are within a module) as well across the entire architecture (e.g., the solution architecture fulfils a clear value for the business that defines the cohesion of its elements). Failing to ensure common purpose and coherency in the elements of a design results in fractured experience that frequently requires manual intervention where automation would be expected. This defeats the purpose of employing technology and introduces risk & cost to the enterprise operation.

Completeness

Having all the necessary or appropriate parts.

There are no missing parts to the design and there are no elements of the design that have been left with a weaker description than the rest. The solution is complete and the architecture balanced.

Organisation & process are often overlooked as valid elements of an architecture. These should to be included as part in the architectural design. Ignoring this frequently results in paper ‘solutions’ that cannot be integrated with the enterprise properly. 

Elegance

Pleasingly ingenious and simple.

The architecture weaves together the ingenious use of technology with processes & organisation to complete tasks and fulfil business objectives. The architecture oozes innovation without confusing the observer, the solutions infuriatingly simple (“why didn’t I think of that?”). Achieving this degree of quality requires dedication, time and bags of experience. Elegance in architecture design is a prize accolade and a characteristic one recognises instantly – this is the x-factor.

Frequently, the time-pressure imperatives of the sponsor limit the architect from dedicating the necessary time to strive towards the goal of elegance. This results in complex or over-engineered solutions that must be unravelled by the implementation team. Complex solutions often result in misinterpretation or redundant features, causing waste or even dysfunction … a costly outcome for a cost-saving measure.

Equivalence

Equal in value, amount, function, meaning, etc.

The architecture separates the design along distinct levels of equivalent concern of its constituents. Therefore, the levels of abstraction are easily distinguished within the design, allowing development at a parity of detail (e.g., conceptual vs. logical). Similarly, functional equivalence can be distinguished and other concerns isolated out of the design consideration (e.g., infrastructure vs. applications). This results in uncluttered and clear designs for each design concern. The principle levels of abstraction concentrate design effort efficiently.

Without equivalence in the composition of architecture, the designs become heavily coupled across boundaries of logical divide (e.g., defining physical servers in a business architecture). This can result in duplicity in the design, which may produce inconsistency (one part of the design is changed but its coupled designs elsewhere are forgotten about) and inevitably lead to ambiguity in its interpretation for implementation. 

Hierarchy

An arrangement or classification of things according to relative importance or inclusiveness.

The architecture demonstrates the inheritance of properties from higher levels of abstraction to lower levels of detail. This order of inheritance recognises patterns to simplify complex problems, using hierarchical relationships to avoid repetition and confusion in detail. As a result, designs that use hierarchy properly are ‘clean’, easier to understand and the relationships between higher and lower levels of detail clear.

Not properly recognising the patterns that indicate hierarchy and repetitive properties in a design can result in duplicity and complexity. This has then risks producing an architecture that is neither elegant nor exhibits the characteristic of equivalence.

Modularity

Employing or involving a module or modules as the basis of design or construction (where module is each of a set of standardised parts of independent units that can be used to construct a more complex structure).

The architecture utilises a science of patterns (either standardised or bespoke) to establish repeatability in the design. The repeatable patterns may vary for each instance, but common characteristics are cleverly recognised and used to produce an efficient architecture. This results in efficient construction, which reflects in better cost, time & resource effectiveness in achieving the design outcome.

Ignoring the benefits of modularising repeatable patterns in design will invariably result in higher cost of design, construction and, ultimately, maintenance. Eventually, this lack of modularity will limit the scalability & extensibility for the implemented design, driving replacement of the construction. Duplicity, complexity and poor maintainability are hallmarks of designs that did not leverage the power of modularity.

Vision

A mental image of what the future will or could be like.

The architecture conveys an inspiring outline of the future of the enterprise within the bounds of the scope of the problem being solved. Inspiration is born of creative innovation in the solution, justification in the language & context of the business and, occasionally, solving more than just immediate problems, but lateral or future issues, thus producing unexpected advantage for the business.

Too often architecture output is dry specification that does not inspire. Project teams are more willing to pull together when excited by the work they will be doing and business sponsors more supportive of initiatives driven by an architecture they can perceive as being more than just ‘bits’ & ‘bytes’. The vision needs to be articulated from the perspective of each key stakeholder group.