LinkedIn: The Nitty Gritty: Can you explain to a CEO what makes an architect different?

<question group="International Association of Software Architects">

The Nitty Gritty: Can you explain to a CEO what makes an architect different?
Well we've been at this for some time and over the last few years have been able to answer this with more and more certainty. However before I post it I want to get some feedback from all of you.

CEO walks in to your office/cube/etc and asks,"I know why I hire good developers/PMs/BAs/IT Ops/etc, so why do I hire architects? What makes them different than other staff? And dont give me any of those mumbo-jumbo technical answers. Just boil it down to one sentence why I should let you keep your high-salary job." What do you say?

Try to answer in one sentence. Try to make sure the answer is VERY clearly differentiated from other roles. For example, "Developers write quality code based on business requirements.", "PMs deliver projects on time and under budget."

...And yes I will post the answer that has come from our research in the next couple of days.

</question>

An architect is someone who translates wishes, expectations, and dreams (e.g. survive in this financial crisis) of a client (you, Mr CEO) into a workable plan and guides others (developers/PMs/BAs/IT Ops/etc) in executing that plan.

See as well https://improving-bpm-systems.blogspot.com/2008/10/discussionenterprise-architect-user.html

In my experience, enterprise architects work simultaneously in the following positions :

• Scribe who keeps up to date the documentation about EA artefacts and the relationships between them. This is the traditional role of an enterprise architect.
• Scout who brings new technologies into the enterprise.
• Salesman who finds good arguments for investments in not-so-obvious improvements.
• Superman who is usually asked to provide a quick rescue for a rotten IT project, often by completing during the weekend work that should have been done over many man-months!
• Sociologist who has to understand the concerns and fears of everyone in the enterprise.
• Servant who is at the service of all others in the enterprise.
• Scientist who uses scientifically proven methods in his/her work.
• Student who is ready to learn quickly new technologies, new tools and new business domains.
• Shepherd who can guide others.
• Secretary “de luxe” who helps others to do some work (although this may be considered as a rather low qualification, it is nonetheless important to achieve the common goal).
• Skipper who can lead complex projects.
• Swiss-knife which can solve any problems.

See also http://improving-bpm-systems.blogspot.com/2008/11/linkedin-is-it-fair-compare-business.html

Thanks,
AS

LinkedIn: What do you think is the essential difference between an architect and a designer?

<question group="The IT Architect Network (3000+)">
What do you think is the essential difference between an architect and a designer?
</question>

I use the article (Architecture, Design, Implementation, A. Eden and R. Kazman, International conference on software Engineering – ICSE, May 3-10, 2003, Portland, OR.) which illustrates the distinction between architecture, design and implementation by the Intension/Locality thesis:
• architectural specifications are intensional (i.e. there may be many possible instances) and non-local (i.e. mandatory for all parts of a system);
• design specifications are intensional but local;
• implementation specifications are extensional (i.e. only one instance is possible) and local.

Thanks,
AS

LinkedIn: Is it fair compare a Business Architect to a building architect?

<question group="Business Architecture Community">
Is it fair compare a Business Architect to a building architect?
Really, does it even make sense? I have been one that used the analogy, but is it a good analogy to use? Why is it that many of us use this one? I know both are hard, both document and are trying to create "blueprints", but...

There is very little science or agreed upon anything when it comes to business architecture. There is no standard certification that is respected by everyone. There is no set of common deliverables you ALWAYS do. There is no governance of business architecture from an industry standpoint. There is a lot of trial and error in business architecture.

This is a great contrast from a building architect. There is rigor and respect when it comes to licensing. There are standard deliverables. There is extreme rigor on governance - building inspectors, laws of physics, etc...

What are your thoughts?

</question>

At first, let’s back to basics to align our understanding.
In the civil architecture in each construction project there are three distinct roles: a client (an individual, or an organisation), a civil architect (a licensed individual who leads a team in the planning and design of buildings and participates in oversight of building construction) and a general contractor (a company which constructs buildings).

A client (maître d’ouvrage) contacts first a civil architect (maître d’œuvre) to communicate his/her "dream"; the latter presents to the client a solution (in some kind of a visual form, e.g. as a drawing or a scale model, because the aesthetic is often very important). After accepting the solution, the civil architect is empowered by the client to guarantee a good way of the construction. The civil architect selects a general contractor and the civil architect works with a foreman (contremaître) – an experienced professional who is in charge of with organising the overall construction including the construction crew.

The separation of duties between these roles is very important – a civil architect and a general contractor are different individuals or companies by obligation (at least in some countries). Such a separation guarantees the appropriate control and quality upon the results. Also, it is interesting to note that there is no an explicit project manager role per se – each role has to carry out some “project management” duties for itself. For example, a foreman is actually a project manager from the side of the general constructor (considering that he/she has come to the management position after experience as a construction worker, but not a professional project manager).

Just guessing the mapping of roles in your case. For example:
“client” = the whole organisation
“architect” = a business architect
“general contractor” = the whole IT department + many external consulting companies
“client’s dream” = merger, changing of unit’s structure, survival in heavy competition, cost cutting, modernisation of legacy applications, outsourcing the whole unit or just its IT environment, portfolio rationalization, etc.

Does it match your reality?

In any case, a business architect has to be armed with a coherent set of proven tools and practices which provides guidance and practical help for the effective transformation of an enterprise to achieve business vision and strategy (i.e. client’s dream).

Of course, a business architect has to work with many step-by-step improvements. We found that the most difficult is to deal with two streams of improvements – those for implementation of the “client’s dream” and those for improvement of the business system itself. The latter are also related to the “client’s dream”, but rather indirectly. Nevertheless, both streams are important, interdependent and to have be intermixed – in some sense a particular business system should be properly “trained” before realising great “client’s dream”.

So far, the most promising approach is a mixture of BPM+SOA as major tools and many supporting ones. (Like in the chess game – it is necessary to play with all chess mates together.) Artefacts, nomencltures, methods, patterns, recomendations etc. are available for this approach.

(Have a look at my talk this summer in Bangalore - http://www.improving-bpm-systems.com/pubs/AS-AW08-keynote.pdf)

Thanks,
AS