What does an architect do? This surely won’t be the last time this question is asked on this forum. It is an important question, and somewhat hard to pin down; especially when one considers the many titles of a Software Architect. There seems to be a general idea of what a software architect does, but many software managers don’t seem to believe the role is necessary, or even distinct: “Can’t we just have one of our senior developers do that?” Sure you can; If you have a senior developer who possesses those skills.
The consensus among those in the software architecture community at large, is that software architecture is to software what building architecture is to buildings. That’s great! But software isn’t a building. A building has steel, brick, and glass. I can get my hands on them; I can look at the building; I can see architecture. Software has 1’s and 0’s. We build these into functions, and data structures, and programs; but the architecture is seldom visible, at least to the untrained eye.
Like any form of design, architecture exists at many levels; and there are many levels at which architects operate. Architecture is design, but it is the design that sets the context for all aspects of its domain. For that reason, it must be given more care than any other aspect of design.
Is there a difference between a Systems Architect and a Software Architect? Surely there is a difference between an Enterprise Architect and an Applications Architect. Of course these are different roles, but the definitions and expectations of these roles are not always clear. Enterprise, Systems, Software, and Application are well understood concepts, so why is this so difficult?
The enterprise architecture defines the systems within the IT function of a company, and how they are interconnected. The enterprise architect is concerned with networks and communication paths, databases, software packages, and deployments.
At the system level, architecture defines the boundaries of an isolated system, the high-level components of that system, and the mechanisms by which they communicated. In the business world, the skills of a systems architect and an enterprise architect differ primarily in scale, with more of a focus on user presentation, and perhaps a bit more of a technical flavor; as a systems architect would more likely be involved in the architecture of an accounting system or perhaps a travel reservation system, that would be a mere component in the overall enterprise view; and of course from a practical view, every system may be considered to be a subsystem of some other system, so there may be any number of sublevels of systems architecture.
Where the domain is an embedded system, the role of the systems architect is somewhat different. In this context there is less separation between hardware and software, and the systems architect may be intimately involved in allocating functionality between the two. In this domain, the architecture is concerned with specification and interoperability communication between individual components of software and hardware, where a software component may be an application, a library, or a device driver; and a hardware component may be an interface bus, a plug-in card, or an integrated circuit. The focus here varies based on the complexity of the system, and for very complex systems, there may be a separate functions for systems and software architecture, the former focusing on hardware architecture and the allocation of software functionality; the latter defining the architecture for the software environment in the context of the systems architecture.
The domain of the application architect is one of software applications, libraries, or device drivers. Generally speaking, the application architecture is created in the context of a pre-defined operating system, with no direct need to access hardware except through a pre-defined API, (Note: these assumptions may or may hold for embedded projects and device drivers). The concerns of the application architect include general structure of the application; data-flow and communication methods among functions, objects, and threads; methods of input to and output from the application; usability and presentation. Some would argue that libraries and device drivers are outside of the domain of application architecture. While perhaps these areas are more specialized, and the implementation methods may differ, I can assure you that the general knowledge applied is the same. These are simply sub-programs that were compiled separately from the main application. Poor architecture on these components can have major ramifications for entire computing platforms.
The network architect is, in general, focuses on a one aspect of enterprise architecture; and I view the database architect as a specialization of the applications architect, focusing on the structure of data and efficiency of access, rather than the control flow of the applications using it. In general, I believe all forms of software architect specialize one of the descriptions above, so I won’t go into any further definitions. No legislation sets these titles in stone, and the lines between them often blur, specializations may come and go, but the general goal of the architect remains unchanged: to create a design which, when implemented faithfully, will reliably fulfill the requirements of the sponsor within an acceptable budget.
Building architects apply creativity to a broad knowledge of tools, structural materials and techniques, in order to provide aesthetic form in a structurally sound package. Similarly, software architects apply creativity to a broad knowledge of platforms, design patterns [1], structures and algorithms, and perhaps some sense of software aesthetics, to create software architectures that blend simplicity, elegance, and robustness.
Now that we’ve defined the concerns of these various types of software architects; Part II [2] will look in more detail at the role they play in the software development (sorry WWISA) [3] construction process.
|
Max is a father, a husband, and a man of many interests. He is also a consulting software architect with over 3 decades experience in the design and implementation of complex software. View his Linked-In profile at http://www.linkedin.com/pro/swarchitect |