Summary
Architecture is about design at the top level, including interfaces and protocols. Architecture of complex systems requires knowledge of the technology in all of the components. In software, there are few constraints on how the components are put together, so it requires discipline to keep things simple and consistent. Bring in an architect when you are trying to integrate many existing subsystems.
—–
Architecture is the high-level design of functional components of a complex system. A functional component can be anything from an arithmetic unit in a computer processor to a database system in a software environment. What an architect does is to define the functioning of the unit (without specifying exactly how the function is to be implemented) and the protocol for interfacing to the unit – that is, how to invoke the function and how to transfer data to and from the unit.
Interface and protocols are the stuff an architect works with. Whether the interface is a bus or an object instantiation in an object-oriented software system, the key objective of the architect is to make the system as simple and as consistent as possible, viewed from the functional block level. Why? Because simple, consistent interfaces and protocols are more robust, are easier to understand and are easier to modify when needed. In other words, more agile.
I worked for a number of years at Quantum, a maker of hard disk drives. Quantum developed their own ASICs (application-specific integrated circuits) for inclusion in their hard disk drives. They also wrote firmware (embedded software) that controlled the whole disk drive, from servo (motion control on the read/write head assembly) to buffering (managing the flow of data into and out of the disk drive). As time went on, the complexity of the firmware and the ASICs went up by orders of magnitude, allowing nearly all of the functions of the disk to be managed by a single chip containing a microprocessor, RAM memory and the ASIC logic.
My dream was one day to have designers of the ASIC logic and the firmware logic use a single integrated tool that would allow the design to be completed before a commitment was made for partitioning the functions between hardware and software. Even though firmware runs for the most part as a sequential process, and ASICs for the most part run as parallel pieces of hardware logic, their functional blocks have a lot in common. Even more important, the definition of an interface between the functional blocks are almost exactly the same for firmware and ASICs.
Since hardware and software can frequently be traded off – complex hardware can be simulated by large software programs running on simple hardware, for example – why not defer the decision as to which parts will be committed to hardware until after all of the design is done? I visualized a designer completing the design of hard disk control logic on an automated design system, then trying out several different variations on partitioning the logic between hardware and software before committing the design to a chip and firmware, each of which would then be automatically generated by the design program.
Alas, the design automation software never converged to a degree that allowed such a tool to be built. ASIC designers still have to ply their trade using design tools that understood logic gates and clocks, sequences of inputs and outputs on signal lines, and parallel processing of signals (and testing for race conditions). Firmware designers, on the other hand, have to write their code as sequences of instructions that execute on a computer processor, access memory, and perform input and output operations using registers (many of them embedded in the accompanying ASIC).
The architect of a disk drive thus must understand both worlds – logic and software – as well as several others, including read/write, servo and mechanical technology. Fortunately, the boundaries between these areas have evolved only slowly. However, in the software arena, boundaries between functional blocks of a system are much more volatile, because there are very low barriers to invention of new ways to interface between blocks or to perform protocols.
Therefore, the software architect’s job is even more critical, because simple and consistent interfaces and protocols will not occur naturally. There are two reasons for this. First, software designers tend to delight in inventing new ways to interface between modules – because they can. And second, legacy systems always demonstrate limitations that must be overcome as systems evolve.
To maintain agility within software designs, an architect must balance the need for evolving functions with the conceptual integrity and simplicity of an initial design. This is why the best architects are constantly struggling to reduce complexity while integrating more and more functions into an evolving system.
If you thought that the work of an architect is only needed at the beginning of a project, consider what will happen if you let existing interfaces and protocols persist forever as you integrate diverse systems into a working whole. The battle for robustness and maintainability will not be won by letting every subsystem persist unchanged. Instead, you need a constant reevaluation of all of the interfaces and protocols. When your designers are facing such problems, bring in an architect.
—–
John Levy helps business managers who are frustrated by the lack of results they are getting from IT or Engineering. He specializes in rapidly getting high-tech teams to align with business strategy and to contribute to business success of the enterprise.
John has been consulting for managers in industry for over 20 years. John’s book on management for technology executives, Get Out of the Way, was published in May 2010. http://bit.ly/9pX1wS
For more information, please visit his website at http://johnlevyconsulting.com ,
Email him at [email protected] , or call 415 663-1818.
