Architect Personas

re: Architect Personas

Graham Chastney — Tue, 13 Dec 2005 12:55:37 GMT

I liked your idea of the triangle.

The issue I have with these definitions and they are similar to ones I have seen a number of times is that they tend to play well in the old world of applications, but not too well in the world of services. I think the issue is primarilly one of semantics, rather than pure role differences. Many organisations regard many services as infrastructure (email, desktop, etc.) and expect the infrastructure organisation to deliver them. For most people these services are what they use all day, every day. The people who do this fit into the definition of solution architect, but they are not software architects. So we end up in a situation where you have application focussed solution architects and infrastrustructure service focussed solution architects. This means that the Infrastructure Architect tends to only exist when supporting an application focussed Solution Architects.

re: Architect Personas

Mitchell Land — Tue, 13 Dec 2005 16:40:50 GMT

I think this is a good start, however, as Graham alludes, it lacks granularity. I think you are correct in your Strategic Architect and Infrastructure Architect definitions, but I think the Solutions Architect requires more delineation. That is, I think you can create another triangle solely for the Solutions area in which you have Software Architect, Data Architect and, perhaps, Integration Architect. Some people are more accomplished in one area over the others. The individual who is accomplished in all three is a true Solutions Architect.

re: Architect Personas

John Q. — Tue, 13 Dec 2005 19:23:40 GMT

Our architect knows a little VB script, but is mostly just very tall. How would you classify an architect that refers to registers as "registries" and win32 as "windows thirty?"

re: Architect Personas

Chris Sterling — Wed, 14 Dec 2005 02:48:37 GMT

This is a great topic. I tend to think that most software architects, covering all three personas, derive somewhat from the solutions architect persona. It seems like the titles data architect, integration architect, and application architect are misleading. I believe that application architect and senior developer are synonymous. The usage of senior rather than architect seems more appropriate when speaking about these sub-personas. I agree with Mitchell that the "individual who is accomplished in all three is a true Solutions Architect". And add that only then are they in the realm of architecture rather than seniority or just design.

re: Architect Personas

Chris Sterling — Wed, 14 Dec 2005 02:49:03 GMT

re: Architect Personas

Mike Williams — Wed, 14 Dec 2005 03:09:03 GMT

This could run and run, but it’s a sign of the growing maturity of the IT profession that there's a discussion at all.
I have also found wild discrepancies in the genuine qualifications of both "Project Managers", and "Analysts".
Analysts in particular differ greatly in personality, dependant on whether they have been developers who have gravitated towards analysis and tend to like formal methods (UML etc), or whether they are business experts who have been dragged towards analysis because of their talent for explaining business processes.

re: Architect Personas

Pablo blamirez — Wed, 14 Dec 2005 15:20:19 GMT

Given that the word Architect derives from the greek words archos (chief, master, leader) and tekhne (art, craft, method, system, skill). It is no wonder that the work Architect when used without qualification is so overloaded.
I think that the above definitions are workable. I take on board the point that was made regarding data architect, integration architect, and application architect. I feel that these are specialism's of the solution architect role and need only be elaborated on verbally if a discussion necessitates it.
I doubt it is worth the effort to try to convey a persons exact job function on say a business card as most job titles in companies have been 'spun' so much that their exact meaning is obscured anyway.

re: Architect Personas

Rupak Rathore — Fri, 16 Dec 2005 12:10:37 GMT

I tend to disagree with just 3 here. I believe there are many more here. From experience, I'm listing down what roles I think should be here:

Enterprise Architect:
Defines what enterprise needs in terms of application and integration.

Application Architect:
Evaluates applications/softwares in line with directions from Enterprise Architect. Makes Build/BUY decision.

Integration Architect:
Defines EAI standards

Data Architect:
Defines flow of information and events (Senior, enterprise wide app-to-app, junior, at app level)

Network architect:
Defines network topology, DR strategies

Technical Architect:
Defines architecture for single app and its interfaces

I believe "Software Architect" is best suited as general term to differentiate from general (Civil) Architects and in all of the above you can replace Architect with "Software Architect" as "Enterprise Software Architect" to better quality them.

re: Architect Personas

Alin — Thu, 05 Jan 2006 12:17:25 GMT

I agree with your 'definition' and separation in three categories. I would like to see events targeting a specific role. I am more interested in Enterprise and Infrastructure Architecture but at times I would participate in Solutions events. This separation of events would allow for better time and content management.

Indeed, as per the other comments, you can brake down every other role and create an Architect position for every category in an organization but where would you stop. Having three architecture levels covering from vision, application and infrastructure would allow for an organizations systems to be complex if needed but not complicated. Having too many architects applying different frameworks and methodologies would guarantee a complicated system but not necessarely a complex one.

re: Architect Personas

Andrew Macaulay — Thu, 05 Jan 2006 20:20:10 GMT

From my perspective, the trouble with this discussion (in general, not just this one) is that different levels of granularity are being mixed together... and the context within which they are being discussed varies by individual. Personally, I can see that all of the definitions above could be appropriate - but also can be seen as wrong in other instances.

However, I do fundamentally disagree with some of the options discussed. Having a general term "Software Architect" fundamentally ignores the Business aspects of solutions - after all, the Architecture is there to deliver business solutions and business benefit, not just IT or Software.

I also have a problem with assuming that Enterprise Architecture = Business Architecture although I know that it is being used in this way in some instances. As we move to a more services oriented world, so it becomes more important to be able to deliver more Services Oriented Business Architectures (i.e. how the business is structured/works). This is where Business Architecture fits.

In this case, I would see Enterprise Architect as providing the connection (roadmaps, guidelines, etc.) between this new Business Architecture and the (IT) systems needed to support and deliver it.

marten.gustafson » links for 2006-02-13

marten.gustafson » links for 2006-02-13 — Tue, 14 Feb 2006 01:20:53 GMT

PingBack from http://marten.gustafson.pp.se/blog/2006/02/13/links-for-2006-02-13/

Architect Personas

Chris Breisch — Tue, 14 Feb 2006 16:16:38 GMT

What is Architecture - Part 2

Arno Nel on Web Development, Web 2.0 and Sharepoint — Fri, 28 Apr 2006 08:38:51 GMT

In this post&nbsp;i asked what Architecture is. Michael Platt, in this post, describes 3 Architect Roles,...

What is Architecture - Part 2

Arno Nel — Fri, 28 Apr 2006 08:39:27 GMT

In this post&nbsp;i asked what Architecture is. Michael Platt, in this post, describes 3 Architect Roles,...

The Technical Solutions Architect Role

Jelle Druyts — Tue, 30 May 2006 23:08:01 GMT