Hi,

In your opinio, whose responsibility is it to discover and define the domain (entity) objects of the system and their properties and relations in a fine grained level?

i think mostly the developers will be concerned about that level of granularity and not an architect.

Developers do the coding and some design. COming to defining domain objects (Class diagrams) falls into the realm of software architect. I work as an Enterprise Architect, We do lot of work planning, tco, roadmaps, blueprints such that solutions or software architects are concerned about design and implemention of a perticular project or application. They won't worry about how it cross cuts through organizations they worry about building silos and I as an Enterprise Architect worry about how the same functionality can be used troughout enterprise. I have to agree/disagree with IVORY Tower theory. I worked as system architect before I became enterprise architect, I have field experience. Infact that helped me to have a wholistic look, which some other architects lack as they are worried about building silos or having job security.

Thanks for your feedback on Enterprise Architecture. Its certainly the bit I know the least about. Note that the "Ivory Tower" term doesn't refer to experience or lack thereof, it refers to involvement in actually building the project. So my question to you is: "When you define a system, do you get involved in the delivery of it? If you don't, will you share the responsibility if it goes bad?"

Regarding Enterprise Architects - 'They typically exist in organisations that have been around for decades, so therefore have built up literally dozens of legacy systems.' This is spot on. Its a different type of challenge, very real/relevant for a lot of mature organizations. Great break-down.

My company and I both title me Software Architect, but I've not considered any of the more specific titles you list above. I do know my role often involves all three of the above descriptions.

I'm the sole architect for an enterprise scale shelfware database package sold to thousands of clients. I define the tools we will use (web services vs. network streams) and as well, at a lower level, specific classes and their contents. In complicated places I'll write the actual code (such as the server's multi-threaded request handler).

At a higher level I have to be concerned with enterprise integration as I'm the guy who designs our software's integration touch points, and have to be sure that clients can blend our system into their enterprise. No one will buy software that doesn't play nice with their existing systems.

So where do I fit? I'm not an enterprise architect exactly because I work on only one system, even though I do fuss with enterprise integration questions. I am a solution architect in that I build and supply one of the integration solutions clients will use once they integrate our software into an existing system. I'm a software architect because I'm responsible for the architecture of a single (albeit large) application. And then, I write code regularly.

I think its important to nail these terms at a community level, but they are still going to remain subjective for quite some time with the lines blurring between each of the types. In the real world, I deal with people who fill the Enterprise Architect role all the time, and they usually don't know the first thing about building software.

So whose responsibility would it be to identify the reusable functionalities of a complete solution? I don't think developers should do their own design as it may not lead to a good entire solution. Each developer may write duplicate codes to achieve common functionalities and the reuse would be minimized. (But getting the participation of developers at the design process is really appreciated.)

If common functionalities of a solution is identified by an architect then it would penatrate through out the system. So don't you think that the architect should participate to the level of designing class diagrams? Or will that responsibilities be delegated to another special level?

Thank you for clarification on Ivory Tower. We do share responsibilities if the vendor or product we selected, for eg a CRM product, couldn't deliver what we thought it should be doing. We look at what kind of APIs they provide for integration into existing systems, we draw blueprints, roadmaps for deliver. Some of us even got fired for selecting a product that doesn't fit into the whole eco system of our company.

Designing classes using OOAD is what a system architect or a group of centralized teams if you would like to have Business object model throughout the company cross cutting through different businesses. Now we are looking at much higher lever with IBMs framework that covers whole organization. I am not saying

Hi Marty,

Have a look at some of the material I presented at last year's team hug that includes an outline of the things an enterprise architect must discover.

The role encompasses much more than the technology itself, or just even just the technological constraints (which is what your solution architect would be concerned with).

Someone has mentioned politics. Sure. Also IT organisational structure, IT processes, business engagement models, and in a truly aligned organisation the org structure and processes of the business as a whole. Vendor engagement and management, service delivery models and agreements and so on.

While the CIO might be the driver of the IT organisation, the enterprise architect might be the head mechanic, keeping the machine running as smoothly as possible.

Nevertheless, if they've lost touch with the technology (and defer to Gartner Group reports for decision making) then the ivory penthouse (as I like to call it) becomes less than useless, it becomes a hinderence to success.

Catchyasoon!

you didn't define "software architect"!

from The Rational Edge:

Characteristics of a software architect

If, in movie-making terms, the software project manager is the producer, since they make sure that things get done, then the software architect is the director, who makes sure that things are done correctly and, ultimately, satisfy stakeholder needs. As the second of a four-part series, this article describes the role of software architect.

The role of the architect is arguably the most challenging within any software development project. The architect is the technical lead on the project and, from a technical perspective, ultimately carries the responsibility for the success or failure of the project.

Here's how the IEEE defines the term "architect":

[An architect is] the person, team, or organization responsible for systems architecture.1

As the technical lead on the project, the characteristics and skills of the architect are typically broad, rather than deep (although architects should have deep skills in particular areas).

The architect is a technical leader
First and foremost, the architect is a technical leader, which means that, as well as having technical skills, the architect exhibits leadership qualities. Leadership can be characterized in terms of both position in the organization and also in terms of the qualities that the architect exhibits.

In terms of position in the organization, the architect is the technical lead on the project and should have the authority to make technical decisions. The project manager, on the other hand, is more concerned with managing the project plan in terms of resources, schedule, and cost. Using the film industry as an analogy, the project manager is the producer (making sure things get done), whereas the architect is the director (making sure things get done correctly). As a result of their positions, the architect and project manager represent the public persona of the project and, as a team, are the main contact points as far as people outside the project are concerned. The architect, in particular, should be an advocate of the investment made in creating an architecture and the value it brings to the organization.

The architect is also involved in organizing the team around the architecture and should actively contribute to planning activities as a result, since dependencies in the architecture translate to the sequencing of tasks and therefore the skills required at particular points in time. On a related note, since the success of the architect is closely linked to the quality of the team, participation in interviewing new team members is also highly appropriate.

In terms of the qualities that the architect exhibits, leadership can also be characterized in terms of interactions with other team members. Specifically, the architect should lead by example and show confidence in setting direction. Successful architects are people-oriented, and every architect takes time to act as a mentor and coach to the members of their team. This benefits the team members requiring help, as well as the project and, ultimately, the organization itself, since one of its most valuable assets (the organization's people) becomes better skilled.

Also, the architect must be focused on the delivery of tangible results and must act as the driving force for the project from a technical perspective. An architect must be able to make decisions (often under pressure), and make sure that those decisions are communicated, understood, and, ultimately, implemented.

The architect role may be fulfilled by a team

There is a difference between a role and a person. One person may fulfill many roles (for example, Mary is a developer and a tester), and a role may be fulfilled by many people (for example, Mary and John fulfill the role of tester). Given that the role of architect requires a very broad set of skills, it is often the case that the architect role is fulfilled by more than one person. This allows the skills to be spread across a number of individuals, each bringing his or her own experiences to the role. In particular, the skills required to understand both the business domain and also various aspects of technology are often best spread across a number of individuals. The resulting team does, however, need to be "balanced." Throughout this article, the term "architect" refers to the role, which may be fulfilled by either an individual or a team.

[A team is] a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable.2

If the architect role is to be fulfilled by a team, then it is important to have one individual who is considered the lead architect, who is responsible for owning the vision and can act as a single point of coordination across the architecture team. Without this point of coordination, there is a danger that members of the architecture team will not produce a cohesive architecture or that decisions won't get made.

For teams that are new to the concept of architecture, it has been suggested that, in order to achieve this common purpose, goals, and approach, the team create and publish a charter for the architecture team.3

Good architects know their strengths and weaknesses. Irrespective of whether or not the architect role is fulfilled by a team, it is often the case that an architect is supported by a number of "trusted advisors." Such architects acknowledge where they are weak and compensate for these weaknesses by either obtaining the necessary skills or working with other people to fill the gaps in their knowledge. The best architectures are usually created by a team, rather than an individual, simply because there is a greater breadth and depth of knowledge when more than one person is involved.

One pitfall with the concept of an architecture team is that it is sometimes perceived by others in the organization as an "ivory tower," whose output is intellectual rather than useful. This misconception can be minimized from the outset by 1) ensuring that all stakeholders are actively consulted, 2) continually communicating the architecture and its value, and 3) being conscious of the organizational politics at play.

The architect understands the software development process

The architect should have an appreciation of the software development process, since this process ensures that all of the members of the team work in a coordinated manner. A good process defines the roles involved, the activities undertaken, the work products created, and the handoff points between the different roles. Since the architect is involved on a daily basis with many of the team members, it is important for the architect to understand their roles and responsibilities. Day-to-day, the development team will often look to the architect to tell them what to do and often how to do it. There is therefore a clear overlap between the role of the architect and the role of the project manager.

The architect has knowledge of the business domain

As well as having a grasp of software development, it is also highly desirable (some would say necessary) for the architect to have an understanding of the business domain.

[A domain is] an area of knowledge or activity characterized by a set of concepts and terminology understood by practitioners in that area. 4

Such knowledge will allow the architect to better understand and contribute to the requirements of the system and be in a position to ensure that "likely" requirements -- i.e., requirements that, based on the architect's domain knowledge, will probably have to be considered -- are captured. Also, it is often the case that a particular domain is associated with a particular set of architectural patterns that can be applied. Knowing this mapping can also greatly assist the architect.

Therefore, a good architect will have a balance of software development knowledge and business domain knowledge. When architects understand software development but not the business domain, a solution may be developed that does not fit the problem, but merely reflects what the architect is comfortable or familiar with.

Another reason the architect needs familiarity with the business domain is that the architect needs to anticipate likely changes to the architecture. Given that the architecture is heavily influenced by the environment in which it will be deployed, having an appreciation of the business domain will allow the architect to make better-informed decisions about the likely areas of change, and the areas of stability, from an architectural perspective. For example, if the architect is aware that new regulatory standards may need to be adhered to at some point in the future, then this should be accommodated in the architecture should such standards be mandated during the life of the system.

The architect has technology knowledge

Certain aspects of architecting clearly require a knowledge of technology; an architect therefore must maintain a certain level of technology skills. However, architects do not need to be technology experts. This relates to the idea in Part 1 of this article series -- that an architecture focuses on significant elements. Correspondingly, the architect need only be concerned with the significant elements of a technology and not the detail. Since technology changes fairly frequently, it is essential that the architect keep abreast of these changes.

The architect has design skills

Although architecting is not confined to design, design is clearly an important aspect of architecting. The architect should therefore have good design skills since the architecture embodies key design decisions. Such decisions could represent key structural design decisions, the selection of particular patterns, the specification of guidelines, and so on. In order to ensure the architectural integrity of the system, these elements are typically applied "across the board" and can have far reaching effects in terms of the success of the system. Such elements therefore need to be identified by someone with appropriate design skills.

The architect has programming skills

The developers on the project represent one of the most important groups that the architect must interact with. After all, it is their work products that ultimately deliver the working executable software. The communication between the architect and the developers can only be effective if the architect is appreciative of the work of developers. Therefore, architects should have a certain level of programming skills, even if they do not necessarily write code.

Most successful architects have, at some stage, been hard-core programmers, where typically they have learned certain aspects of their trade. Even as technologies evolve and new programming languages are introduced, good architects can abstract the concepts in any programming language and then apply this knowledge to learning a new programming language to the depth required. Without this knowledge, the architect will be unable to make decisions with respect to the architecturally significant elements of the implementation, such as the organization of the implementation and the adoption of programming standards, and a communication barrier will emerge between the architect and the developers.

The architect is a good communicator

Of all of the "soft skills" associated with the architect, communication is the most important. There are a number of dimensions to effective communication, and the architect needs to be proficient in all of them. Specifically, the architect should have effective language skills, including speaking, writing, and presentation abilities. Also, the communication is two-way. The architect should be a good listener and observer, as well as a good talker.

Being able to communicate effectively is a skill that is fundamental to the success of a project for many reasons. Clearly, communication with stakeholders is particularly important in order to understand their needs and also to communicate the architecture in a way that secures (and maintains) agreement with all stakeholders. Communication with the project team is particularly important, since the architect is not simply responsible for conveying information to the team, but also for motivating them. Specifically, the architect is responsible for communicating (and reinforcing the communication of) the vision for the system, so that the vision becomes shared and not something that is only understood and believed in by the architect.
The architect makes decisions

An architect who is unable to make decisions in an environment where much is unknown, where there is insufficient time to explore all alternatives, and where there is pressure to deliver is unlikely to succeed. Such an environment is to be expected, and successful architects acknowledge the situation, rather than try to change it. Thus, the architect needs to be "thick-skinned" since they may need to correct their decisions and backtrack at times during a project. As Philippe Kruchten puts it, "The life of a software architect is a long and rapid succession of suboptimal design decisions taken partly in the dark."5

An inability to make decisions will slowly undermine the project. The project team will lose confidence in the architect, and the project manager will be concerned because those waiting on the architecture cannot make the required progress. Here's the greatest danger: If the architect does not make and document decisions about the architecture, then team members will start to make their own, possibly incorrect, decisions.

The architect is aware of organizational politics

Successful architects are not geeks only concerned with technology. They are also politically astute and are conscious of where the power in an organization resides. This knowledge is used to ensure that the right people are communicated with and that support for the project is aired in the right circles. To ignore organizational politics is, quite simply, naïve. The reality is that there are many forces at work in organizations that lie beyond the project team delivering the system, and these need to be accounted for.

The architect is a negotiator

Given the many dimensions of architecting, the architect interacts with many stakeholders. Some of these interactions require negotiation skills. For example, a particular focus for the architect is to minimize risk as early as possible in the project, since this has a direct correspondence to the time it takes to stabilize the architecture. Since risks are associated with requirements, one way to remove them is to remove or diminish the requirement with which the risk is associated. Hence the need to "push back" on such requirements so that a mutually-agreeable position -- between stakeholders and architect -- can be reached. This requires that the architect be an effective negotiator, able to articulate the consequences of different tradeoffs.

Summary

This article has focused on defining the characteristics of a software architect. The remaining articles in this series will focus on the characteristics of the process of architecting and the benefits of treating architecture as a fundamental IT asset.

Interesting point of view.