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 New York 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 acknowledgment 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.
