Qualities of an Architect

Here's a useful set of qualities required in an architect that I found in a comment from Kevin Lee Smith on Chris Eaton's excellent blog.


Pragmatic
========
They are always looking to understand what the perfect solution can be but tempering that with a more commercial and tactical view that relates to the realities of getting things done.

Enthusiastic
=========
They are passionate and enthusiastic about what they do and how they do it.

Agnostic
======
They see all things from Supercomputers to paper, pencils and people as possible solutions to business problems and will propose the best fit for any given context not what their favourite is.

Articulate
=======
They are at home communicating with everyone from the board to the graduate programmer or claims clerk and in scales from one to one to speaking to hundreds at conferences.

Persistent
========
They will not be steamrollered and will stand up for what they believe in.

Strategic
=======
They are focused on long term and lasting benefits rather than short term benefits which compromise long term objectives.

Altruistic
======
They are selfless, and always focused on what is best for the organisation not what is best for them.

Diplomatic
========
They are sensitive to other peoples drivers and the political context.

Open
====
They are open to critique and happy to be proved wrong and will assimilate and apply new information as it arises.

Generalist
========
They have a Broad base of technical and business experience.

Persuasive
=========
They persuade others of their views and the way forward rather than dictating.

Learn
====
They pick up and assimilate new information quickly and easily and are always open to new ideas, businesses, technologies and processes.

Investigate
========
They have a nose to seek out things that don’t makes sense or could pose threats and risks and the ability to get to the bottom of them.

Abstract
======
They abstract levels of detail to a higher levels to aid understanding and to see relationships and patterns.

Expose
======
They seek to expose pertinent information to business leaders to enable them to make more informed decisions.

Facilitate
=======
They guide discussions and workshops in order to get the best out of people.

Lead
====
The lead, motivate, inspire and enable others to reach their potential and create the environment where people want to follow them.

Reference Models, Reference Architectures and Reference Implemementations

I recently stumbled across a blog entry by J.D.Meier on the difference between Reference Models, Reference Architectures and Reference Implementations.  The difference between the first two was something that has never been entirely clear to me, so I found the post very useful.  


After reading this, my interpretation now, if I've understood it correctly, is that a Reference Model is a model of something that can be referred to for various purposes, such as when creating reference, or otherwise, architectures.  I think the SaaS/PaaS/IaaS Reference Model is the best illustration of this.  I suppose a glossary could, in a sense, be deemed a reference model.  I suppose you could call it a model of reference material.  Also, a Reference Model cannot be interpreted as an architecture itself.  


In contrast, a Reference Architecture appears to be, an architecture depicting a solution to a problem space to which other architectures and specifications can refer to.  Now this may be an generic architecture for a pattern, or an specific architecture for a specific problem, but either way it is the architecture which gives aerial views of the solution.


For example Open Group has a SOA Reference Architecture (as I'm sure a number of major players do). As pointed out, the MSDN pet shop application has a Reference Architecture.  Patterns can also have reference architectures, such as this one also from Microsoft.


I suppose Reference Architectures are used as inputs into Technical Architectures, Designs and Specifications, which in turn should refer back to the Reference Architectures.  I also believe that Reference Architectures are on the middle row of Zachman. 


Reference Implementations are the only implementations of Reference Architectures, and an proof and an example that the Reference Architecture is integral and as a guide to production implementations.  In my mind production implementations should never be created from Reference Architectures, they should only be created from the Technical Architectures, Designs and Specifications that are created from the Reference Architectures.


That's my understanding today anyway.

Architect Role and Skills

Here's an interesting presentation on the IASA's five pillars of architecture by Jim Wilt (Microsoft).

For background, the IASA determined the following pillars for IT architects:

• Business Technology Strategy: architects need basic business competence and understanding of the business of their business. Otherwise, they are not able to support their organization’s or customers' business goals. This knowledge comprises financials, IT business strategy innovation & validation, as well as industry concerns, trends, standards, and compliance.
• IT Environment refers to the architect’s “skills in the functional and procedural aspects of technology organization to ascertain solution and organizational maturity.” It is about running things and creating new things in terms of the application development processes, technical project management, leveraging platforms and frameworks, change management, asset management, governance, as well as testing and quality. For example, architects should be familiar with industry trends, understand the benefits and limitations of technologies, but also know about methodologies and technologies being used in their environment.
• Quality Attributes are mapped by IASA to four categories: Qualities that define usage aspects such as usability, developmental qualities such as changeability, operational aspects such as performance and last but not least, security. Such qualities are typically cross-cutting and lead to trade-offs due to constraints in time, cost, requirement and resources. Wilt emphasizes that these qualities need to be measurable and monitored. They also need to be practical. While customers might be interested in five nines of availability, they might not be willing to pay the price for achieving this quality goal.
• Design skills are an “architect’s primary tool in delivering architecture strategy and product to the business.” As Wilt emphasizes, it is not only about architecture creation but also about design review. It is not about “pretty pictures,” but about  “justifications, reasons, and trade off considerations” when capturing decisions. Skills required in this area include knowledge of design methodologies and techniques. Of course, architects should know tools for design, and also design artifacts such as patterns, styles or views. To achieve appropriate design decisions, architects must  be able to tie their decisions to business requirements.
• Human Dynamics is about managing and influencing people as well as interrelationships in the context of an IT project or environment. There are many skills required by architects in this context, as Wilt explains. They need to manage the culture but also deal with customer relations and with peers in the project environment. Although, architects mostly neither own line management nor project management responsibility, they require leadership and management skills. Collaboration and negotiation skills are essential. So are presentation and writing skills.

IASA have organised their skills matrix based on the five pillars, which is more of a course catalogue, but it's good food for thought.

As an alternative, it's always worth referring to the SFIA v5 skills framwork, particularily the section on strategy and architecture, and then there is always the TOGAF v9 skills framework.

Lastly, Graham Berrisford's presentation on EA vs SA roles is another interesting one.

Jamie's stag do

-- Posted from my iPhone

Eriksson-Penker Business Extensions to UML - Reference Card

 

 

http://amor.fri.uni-lj.si/dejan/delo/studenti/id/UML%20(Eriksson-Penker%20Business%20Extensions).pdf