Software Architecture Notes

Software Project Architect Role & Responsibilities

Ask two people what a developer does and you will pretty much the same answers. So, too, if you ask what a tester does. Or a project manager. Sure, there will be differences in wording and emphasis. But the basic answers will be the same: a developer writes code, a tester tests things, the project manager allocates resources to tasks, or something to that effect.

But there is a lot more spread if you ask what an architect does. Is it a title to promote Really Senior technical people into so that HR will let their salary progress? Does it mean membership in a group with some kind of over-arching technical responsibility? Is it the folks that create and maintain the corporate network?

And then there are the variations...

Do you mean an application architect, or a data architect? Enterprise, technical, security, infrastructure or network architect? Which of these are the same? Which are alike? Which are different? Why are they different? Put in picture here

Here is another murky bit. Most interesting systems have an architecture. Far fewer have had an architect. Somehow the work of architecture gets done, often though no architect is present to do it. So, do you need an architect? If so, when?

This is too big a mess to sort out in one go. A (slightly) more manageable bit is the role and responsibilities that go with the titles "application architect", "technical architect", "software architect" and "project architect." These four titles seem to be about pretty much the same thing: making the earliest technical decisions that the rest of the project team has to live with. This page explores what that is about. Other pages in this site will deal with the transitional role "enterprise application architect" and the separate role of "enterprise architect", though they will be touched on here.

Before getting into the meat of things, a bit of context may be in order. First, the architect role and responsibilities here are based on what one person has seen in their own peculiar path through this business. It does not line up with any "official" definitions that I am aware of. There are official organizations (see the World Wide Institute of Software Architects Put in link here, for instance) that would disagree. Also, Agile methodologies do not clearly describe an architect role, and tend to fall into the "don't need 'em" camp.. The Rational Unified Process (RUP) architect is the closest. But RUP concentrates on current project functionality. The RUP architecture role does not have as clear a focus on post-release issues.

Second: since the subject is software project architects it is worth knowing what kind of projects. It include primarily business systems built around "transactional records" (usually in a relational database), with standard Create/Read/Update/Delete (CRUD) functionality, along with various "business rules." Included are projects for internal use, projects under contract and software products (primarily for sale to business customers). Development sizes range from a few folks for a few months to hundreds of developers working on simultaneous releases of a product family for years. Further variations include enterprise scale Web projects, live, real-time pricing of complex financial derivatives, communication protocol testing and scientific simulation. Distribution ranges from a single user through small work-groups to global enterprise infrastructure systems.

There are some really interesting kinds of projects that are not on this list. Products for sale to end users are not included. Neither is avionic, real-time control or life-rated software. Also not listed are truly mega-scale systems where staff levels exceed a few hundred. If these are your areas of interest the stuff here may or may not be helpful to you. If your path has taken you through other kinds of projects you may well have come to different conclusions.

Finally, the architect role as a separate job responsibility is rarley important on smaller projects -- the team just does the right things because the universe of choice is smaller. In much larger projects there may be multiple architects who share responsibilities any number of ways. That is too much variation to handle here. It is simpler to talk about "the project architect" or "the technical architect" or whatever (titles that will be used interchangeably.)

Hopefully that gives you some idea where this is coming from.

Architecture is a Separate Technical Responsibility

This is the story of how I learned that architecture was a separate thing from design and analysis.

After ten years of doing some of the other jobs in software: coding, design, requirements gathering, project management and things like that, I was put on the architecture staff of the largest project I had ever seen. When I joined a new release was being planned. The first drafts of the requirements were being passed around for review and negotiation. It was about this time that I had a brief conversation with my boss, the Director of Architecture, that summed up the whole thing.

In the next months he was proved right. Before the requirements stabilized enough for the official "design" phase to start we nailed down lots of things . Platforms were chosen. The system was broken into tiers. The responsibilities of each tier were roughed in. Portability and integration approaches were defined. Languages and compilers were chosen. Testing approaches were refined. New skills were trained for and hired in.

Each of these were important and expensive decisions. And each was only loosely tied to any specific user-facing requirement. No functional specification, use case, scenario or user story forced these decisions; few even made mention of them.

There were two lessons in this experience. First, the only things needed to start the architecture are knowledge of the kind of data the system is to manipulate, and the target "ilities." Second, the deliverables for satisfying the "ilities" precede and are separate from the design.

Architecture Concerns are Different

This part has to be snuck up on a bit.

Everyone working on a system makes creative decisions. And each decision can be wrong: Code can have a bug; a design may not do what a user really wants. Validation finds errors so that they can be fixed. The most common form of validation (okay, okay, officially its verification) is testing. Take the standard testing view of validation and extend it a bit:

On the left are the creative processes. Those above constrain the choices available to those below. Validation is on the right. Processes on the left are validated on or near the same line to the right.

Cycle time also varies up and down. There will be multiple edit/compile cycles within the implementation of a single detailed design. Multiple detailed designs will support a single functional design. Multiple functional designs will be needed to implement the business requirements. Each step has a longer timeframe than the one below it.

Architecture cycle times are very long. The project architecture is validated two ways: by explicit testing and by holding up during maintenance. Of these the more interesting one is validation during maintenance. Is the system as flexible, conformant, portable, available, reliable, secure, etc. over its lifetime as planned? What worked well? What did not work well? There is really only one cycle per project to validate these decisions.

The original build team will have moved on to other things long before these questions can really be answered. The only time an architect gets strong feedback during a project is when things go terribly wrong. So, it is not surprising to find that most architects have at least one "failed" system where they learned the bulk of their craft. While the creation / validation cycles explains how this happens, failing or nearly failing on a multi-million dollar project is an awfully expensive way to teach someone how to do a job.

The system/enterprise architect's feedback cycles are even slower. The ability of the network architecture and server infrastructure to support the business is only validated by major new project releases, or by entirely new and unimagined projects. The decision to decommision one set of technologies while staffing up another takes years and several projects to validate.

Architecting within a Team

This long view means that the project architect has a bit of a balancing act to do. Their decisions will constrain the project team for the life of the current project. But the choices the architect makes are influenced by things beyond the delivery horizon of the current team.

The rest of the delivery team can (rightfully) see this as a problem. It is quite common for the development team to want to "get the architect out of the way" so that they can get down to delivering what this project is all about. This can be the case with the project architect; it is very often the case with the enterprise architect or enterprise architecture team.

How can an architect remain a valuable part of the team? How can they help the team achieve the project-local goals, while making sure that the longer-term goals are also addressed?

One part of the answer is that the architect has to understand when and how they are causing pain to the team. If an architectural choice is going to cut out or reduce important choices in the business analyst's, developer's or tester's domain, the architect needs to understand those jobs well enough to empathize with the pain they are causing. It also helps if they can propose ways for the team to achieve its project-local goals within the constraints. And, when the team explains that that just isn't going to work, then the architect needs to be able to re-balance the needs of the present with the needs of the future in a realistic way. This implies that an architect should be at least a compentent, if not expert, developer, tester and business analyst.

A second part of the answer is that the architect must be able to explain their decisions so that they make sense to the project team. Since most of the reasons come from maintenance, the architect should have actual maintenance stories to back up their reasoning. This means the architect should have some years of experience maintaining a project.

Thirdly, the architect has to be part of the "boots on the ground" team that builds the product. Too often the architect is someone who arrives to periodically sprinkle white board dust on things and then move on. If the architect is going to get real traction with the team, they need to be tied to the same delivery goals. They have to be willing to be there nights and weekends along with the rest of the team to make their decisions work. When the user's object to things, the architect cannot hide behind the team -- they have to be there to answer the objections themselves.

Architecture is a Project Leadership Role

Architecture is one of three views that crosses the entire project. The other two are the project manager and the (chief) business analyst. These are project leadership roles because they have project-global responsibilities. They must form a leadership team, because their responsibilities interact.

The architect makes the ilities "come true." The business analyst equally makes the function of the system "come true." The project manager gets and allocates resources and keeps the machinery running smoothly.

All three have to agree on the major and minor forms of the project methodology. The architect will specify equipment that the project manager needs to get their hands on and pay for. The business analyst and the architect will agree on which functions are affected by which "ilities", and they will trade off technical costs for perceived user value. All three will be governed by the business case for the project that the business analyst puts together and keeps up to date. The architect and business analysts will contribute to the project risk list and mitigation strategies.

My Project Doesn't Have An Architect. Will We Die?

Almost certainly not, of course. The vast majority of projects don't need an architect at all.

An architect is a good idea when getting and keeping one is less expensive than the value that they will add to the project. This is a simple return on investment model that can as easily be applied to any potential member of the project.

So, it makes good economic sense to have an architect if the (net present value) of the value they add is greater than the net present value of having them around. What are the benefits, what are the costs, and what swings the balance strongly one way or another?

There are two ways that an architect can add value : improved return on software maintenance, and reduced risk on new technology projects.

Improved Return on Software Maintenance

First is the improved post-delivery value of the project. Here is how that works. Good architecture means that the maintenance lifetime of the application will be longer. Simply, it will be longer until the application needs to be scrapped. It is radically more cost-effective to get new business value from software by changing an existing system (maintaining it) than scrapping it and starting over, A more maintainable system will a) increase the business value extractable per unit of maintenance effort and b) extend the maintenance life of the system, the architect's value is the net present value of this improved benefits stream.

Here is one way to think about the dollar value of improved maintenance. The cost of maintaining a software system will be roughly four time the cost of the initial development. Only a small part of that will be post-production error correction. The majority of it will be changes to realize new business opportunities. Set the cost of adding new capability in maintenance at 1/4th the cost of building the same capability into a new system.

Reduced Risk on New Technology Projects

Second, is the decreased risk associated with introducing new technologies. New technologies mean re-thinking how to make the "ilities" come true. An architect should substantially reduce the risk of project failure on new technology projects.