Software Projects and the Architect

In the early days of software development little thought was given to how the software applications and systems we built were architected. There were several reasons for this: firstly, software development being new, the concept hadn’t been thought of, and secondly we didn’t realize how important architecture was to the cost of maintaining our applications and systems. Upon sober reflection, we probably should have foreseen the need for planned architecture and architects because building software isn’t radically different from building any other structure, for example buildings and bridges. We can’t go back and undo the damage done by the lack of foresight that led to badly architected applications and systems but as project managers we can avoid making this mistake in our next software development project.

Today most organizations whose core competencies include software development recognize the importance of architecture to their business and have satisfied this need by creating the role of architect and making this person responsible for the architecture of all the software applications and systems they develop. Even organizations whose core competencies don’t include software development, but who have invested heavily in IT, have created this role. These people may be referred to as the Chief Architect, Head Architect, or Strategic Architect. Wikipedia identifies 3 different categories of architect depending on the scope of their responsibilities: the enterprise architect who is responsible for all an organization’s applications and systems, the solution architect who is responsible for the architecture of a system comprised of one or more applications and hardware platforms, and the application architect whose responsibility is limited to one application. The category and number of architects will usually be constrained by the size of the organization and the number of applications and systems it supports. Regardless of what the organization you work for calls them, the software architect has a key role to play on your software project.

Your job as project manager of a software development project, where a software architect is in place, is to ensure that their work is properly defined and organized so that your project receives maximum benefit from their expertise. If the organization does not have an architect in place you will have to identify someone on your team to fill that role. What is not acceptable is to plan the project without any acknowledgement of the need or importance of the architect. This role requires as much knowledge of the system components as possible, including software and hardware knowledge. It also requires deep technical knowledge of the technology being used, both hardware and software and strong analytical skills. The person (other than a software architect) who most probably possesses a skill set similar to this one, is a business or systems analyst. Depending upon the size and complexity of the existing system, and your project, existing skill sets may not be sufficient to meet your project’s needs. There are ample training opportunities available so pick one that most closely suits your needs and have your candidate attend. If your project has adequate budget to pay for the training, fine. If not, keep in mind that the skill set acquired by the trainee will be available to the organization after your project is completed and your project should not have to bear the full cost of the training.

Now that you have a qualified software architect engaged for your project, you need to plan that person’s tasks to take maximum advantage of their skills. I recommend engaging the architect as early on in the project as possible so that they can influence the definition of the application or system being developed. The team that defines the business requirements to your project will be from the business side of the organization and have deep knowledge of how the business runs but little knowledge of the existing systems and technical features of the hardware and software that will deliver the solution. Having a software architect available during requirements gathering exercises will help you define requirements that leverage existing system and solution platform strengths and avoid weaknesses. Leaving their input till a later phase exposes your project to the risk of re-engineering the solution to fit existing architecture or avoid solution weaknesses, after the fact. Involve the software architect in requirements gathering exercises as a consultant or SME (subject matter expert) who can point out risks in defining requirements and offer alternative solutions.

The key deliverable your architect is responsible for is the architectural drawing. This is not actually a drawing but a mix of drawings and text. The drawings will represent the various components of the system and their relationship to one another. The text will describe data elements, relations between various architectural elements, and any standards designers must adhere to. The drawing may be a new one to represent a new system, or it may be an update of an existing drawing to reflect the changes to an existing system made by your project. The development of the architectural drawing is the first design activity in your project schedule. The drawing is used in the same fashion that engineering staff and skilled craftsmen use an architectural drawing of a building or bridge. Analysts and programmers will use the Business Requirements Document (BRD) to tell them what features and functions to design and the architectural drawing to tell them how their software must fit together with other software in the system, any constraints the system places on their design, standards the new software must meet, and what critical data elements look like. The information in this drawing will depend on the solution chosen, the hardware chosen, the existing system and the complexity of the project. For example, projects using an Object Oriented solution will have 4 layers: a user interface layer (the layer the user sees), an application layer (where the work is done), a domain layer (where business logic is applied), and an infrastructure layer (for logging messaging, etc.). Other solutions may call for more or fewer layers.

Software development projects which rely on a relational database to store and retrieve large volumes of data will have a database architect who is responsible for the design of the database. The database architect should be a member of your project team and their design should be coordinated with the system architecture so that the data elements in the architectural drawing are defined the same way as they are in the database’s data dictionary. Database design is critical to system performance. Poor database design, or database design which does not support the applications using it, will deliver a system with poor performance so database design and architectural design must be inputs to one another to yield a well integrated system with the performance characteristics required.

The architectural drawing must be approved by the project sponsor, project steering committee and the organization’s enterprise architect/chief architect/head architect where that person is not the architect on your team. In many cases people other than another architect will not have the ability to determine whether the drawing contains all the information required by the project, or whether the system design is sound. They will be able to determine that each category of information has been addressed and that the drawing meets any requirements defined for it in the Project Charter,Statement of Work (SOW), or scope statement. Once the drawing has been approved it should be communicated to the analysts who are responsible for producing design specifications.

The software architects role does not end with the production of the architectural drawing, indeed in some software development lifecycle (SDLC) methodologies this drawing will be produced iteratively. It may be produced in stages such as the infrastructure layer first, the domain layer next, etc. or it may be produced iteratively, one new version for each iteration. Even projects using Waterfall SDLC methodology won’t necessarily produce a final drawing during the project planning phase because they don’t need to. The designers need to have a drawing that provides them with the information they need when they need it and you may need to begin design work with the drawing you have in order to keep to schedule.

The architect must also ensure that the design captured in Functional specifications and detail design documents conforms to the constraints placed upon it by the architectural drawing. To do this they must review the designs to determine compliance. The architect should be a member of any peer review teams reviewing design. This may not be possible, especially if you have to share an architect with another project or operations so at minimum the architect should review each design and ensure compliance with their architectural design, or identify gaps where it does not.

The hardware and operating systems which are components of the system architecture are areas of oversight for the architect. Projects which call for procurement of these items, or outsourcing of the development of any applications, should engage the architect to contribute to product and vendor selection criteria. Some architectural drawings may specify hardware and software depending on the solution being implemented, in which case the information should be included in the architectural drawing. Where requirements for these things are less well defined, the architect should make certain that selection criteria properly reflect their architectural requirements and that the statement of work for any outsourced software is correctly written. In projects where software development work is outsourced, the architect's role will be the same as if the work were being done in-house. Large projects which require the vendor to staff their team with a software architect should have their architectural design overseen by the architect for your project.

Finally, the architect should also be called upon to analyze any changes to software design or functionality that could cause a change in the architecture. Your architect will be the right person to analyze any request to determine where a change in the design of one system component would impact on other components of the architecture. Once the architect has determined if a change in other components would be required, and what the nature of that change would be, it’s up to your design and build gurus to assess the cost of that change.