[ or in any other place in the world for that matter :-) (Hawaii still pending as proposed site1 for our architects, as it is somehow midway between Europe and India...) ]
Wow, this is a challenge! I've always wanted to write down some of the things I had to do to set up a product line for software for televisions, as I felt this was more than software architects usually do, and less than software architects actually should do. And here's an opportunity to document this and with it feed Paul's, Len's and Rick's2 Birds of a Feather session on what software architects actually do (here's the link for WICSA 2005 participants).
Mind you, some might not call me a practicing architect, since I work for Philips Research. But in the period 1998-2000 I was asked to setup a product line for our consumer electronics product division, and worked effectively as one of their architects. Actually, there were three of us, but I won't go into those details here...
Define concepts: like components, subsystems, layers, packages, interfaces, tasks, diversity, et cetera. These form the corner stones of the architecture and should be unambiguously defined. In that time (1998), there was no standard for this (I'm not sure there is one now :-).
Communicate concepts: and not only to developers, but especially to project managers, team leaders, configuration managers, et cetera. All should have the same view (and believe me, that's not easy to achieve :-). Even the name of a subsystem knew many variations: txplf, txtplf, txplatform, TxPlf, ...
Select technology: in our case, the software component model forms an essential ingredient for our product line, and we designed it ourselves to specifically match our needs. The accompanying Architectural Description Language helps us to manage complexity... Diversity, complexity and lead-time were our main architectural drivers (and resource constraints).
Define top-level architecture: in terms of layers and major subsystems. We did not define the internal architecture of subsystems, nor did we define the interfaces between subsystems (but see next point), as we did not want to be the bottleneck there. Note that in that sense we have kind of a federal architecture, where relative autonomous subsystem teams negotiate interfaces between themselves.
Explaining the top-level architecture: explaining the federal architecture as described in the previous point was also a non-trivial issue. Again, the technical people had to be convinced first, but teaching this to non-technical people was equally - if not more - important, as processes and teams had to be organized around the architecture.
Define styles and patterns: though we did not define precise interfaces between subsystems, we did define certain patterns and styles that should be used unless there were strong reasons not to. Strategies for multi-threading and notifications are examples of these.
Design an execution architecture: in an embedded resource constrained system it is important that performance is designed into the system on beforehand. We solved this by recognizing a few critical tasks, i.e. with fairly-hard deadlines, and using late-binding mechanisms to solve the more soft real-time requirements. The only mistake that we made was running user interface animation and setting up new screens at the same priority level...
Align software and hardware architecture: the hardware architecture of our televisions was composable. This meant that it was very easy to create variants of products just by composing different sets of hardware components, much easier than e.g. developing new hardware components. The software architecture needed to exhibit the same property, so we decided to mirror the hardware architecture in software3 (in the lower layers). (This decision backfired on us when a new generation of hardware was developed and people thought the software would run on that without modification...).
Create a build environment: the ability to build multiple products from a single source code archive is an important ingredient of a product line. The build scripts are normally implemented by the configuration management team, but in a product line building should be fully in line with the architecture, especially when compile-time techniques for managing diversity are used.
Interface to configuration management: also, in a product line, the way to manage configurations needs to be aligned with the product line architecture. Traditional configuration managements systems handle compile-time diversity only, and in our case we wanted late decisions on whether to use compile-time or run-time binding, so use of traditional CM techniques was not possible.
Explain build and CM strategies: we created a three day course to explain the whole approach to our developers. The build environment consisted of 20,000 lines of code. Again, this backfired later when attempting to introduce the same way of working in another division, as they believed their tools were much smaller and didn't require a course. Actually, they had 20,000 lines of scripts, and learning this 'on the job' did cost more than three days, but who will ever measure that?
Define documentation: documenting components and interfaces in a product line is different from the traditional way of working. Instead of requirements documents for components, we produce component and interface datasheets. Design of these was not that difficult, but convincing the different development organizations that they should change their development process was a tough job... We decided in the end that certain information vital to the product line should be written according to our standards, but other information could be written according to the local organization's standard.
Define architecture documentation: traditionally, an architecture document is written at the beginning of a project, and then never changed anymore. We introduced the concept of architectural notes, which describe one particular topic by stating the problem, possible solutions, the chosen solution, and consequences. These architectural notes may refer to other architectural notes for reference, or overruling them, much in the way Requests For Comments (RFC's) are organized in the internet world. Philippe Kruchten's design rational 'cards' are very similar to this.
Set up a distributed repository: we split the development into subsystem and product projects, with an 'm' to 'n' relation between them. Instead of having a single distributed CM system, we created a separate CM system at each development site and used the intranet to publish releases of subsystems and products as ZIP files. There were formal releases and daily releases (for informational purposes). The latter was difficult to get in an organization that wanted to reach CMM level 5 and only publish approved results. In the end, we got our way, and up to today our TV organization has - within Philips - the most visible software to all of its members.
Changing the organization: many of our product development groups were organized - and had processes - to create a single product. Changing this into either teams that produce subsystems for use in multiple products, or teams that produce products built from subsystems, was a major challenge that involved discussions with project leaders and development managers.
Organize meetings: as our development was distributed (at some point 7 sites or more), we decided to have three-monthly face to face meetings of two days for all of the software architects. This was organized by the global architects, and tolerated (see later) by project leaders.
Setting up a forum/Wiki: or actually a news server, since I did not know about forums and Wikis at that time. My observation was that a lot of e-mails were being exchanged, and phone conferences being held, and that a lot of useful information was circulating in limited and changing subsets of people. At one occasion, my roommate received an e-mail that had been sent around at least a dozen times before he was added to the cc: list, and he knew immediately that the problem that was discussed had no solution. So the e-mail discussion wasted a lot of time. Unfortunately, I did not succeed in getting the news server to be accepted. Developers and architects just didn't have time to access the new server; they were too busy answering e-mails and participating in phone conferences all the time... :-(
Architecture centered documentation: since we have a formal component model that describes the composition of all products, it would be relatively easy to build a system that allows developers to annotate architectural elements such as components and interfaces, e.g. with problems found, solutions to problems, tips and tricks, et cetera. This could come close to Mary Shaw's credentials. This desire did not fail because of social psychological problems, but just because I didn't have enough time. I still think it's a good idea...
Talking regularly to project leaders: the project leaders formed their own community, almost fully separated from the architectural community (although project leaders did communicate with their own architects). Decisions taken at architectural meeting were rarely communicated well to the project leaders and vice versa. Publishing the minutes of project leader meetings to developers was stopped at a certain point in time due to supposably sensitive information in the minutes.
Introduce an ADL as design language: well, this did work to a certain extent. Most developers draw Koala pictures when creating and discussing designs. But they did this on their white boards, and they didn't use the tooling to check designs in a premature stage. Koala was more used as a module interconnection language than as an ADL, although it has sufficient potential to be an ADL...
Roadmapping and planning: initially, architects were responsible for the products to be built first, and were not concerned with planning of these nor with future products. Project managers did the short term planning; long-term product planning was done by an entirely different set of people. We introduced the notion of road-mapping using a tool (yes Len, a technical solution to a non-technical problem :-) that allows to describe features provided and required by subsequent versions of subsystems. We even invented how to integrate this into our ADL, so that in principle we could assess whether our architecture is consistent at any point in time in the future. Although this approach looks promising, we haven't succeeded in introducing it yet (since a lot of effort is involved into introducing the technology and tools and helping people to initially fill-in the data).
Talking to requirements managers: in our organization there was a unidirectional flow of information between requirements and development teams. This is a pity, since developers may help to invent new features (at least it should be an interaction).
Talking to product management: product management could have been more aware of the possibilities and impossibilities of software development.
Follow hardware development: Although we had a good start with respect to the first generation of hardware, we were not involved in the definition of the second generation of hardware, and as such we encountered an unnecessary large set of problems when 'porting' our software to this new hardware (as explained above).
Selecting people: in the beginning we had a strong saying in selecting people to become subsystem or product architect. At later times, we were only informed of such selections.
On the job tutoring: a global architect should know what subsystem architects can and cannot do. A global architect should tutor/guide/help/advise a subsystem architect in his initial period as subsystem architect. This may require spending an hour per day at first, an hour per week later, et cetera. This process should be repeated at other levels of the architect/designer hierarchy. In practice there just isn't time to do these things... [a better term for tutoring may be 'mentoring'].
This list is empty... :-)
On hindsight, many of the topics mentioned above are of a
technical nature. But that's what an architect is mainly for :-) !
Still, I would estimate that at least 40% of the job of an architect is
non-technical in nature, talking to different stakeholders, explaining and
tutoring and mentoring people, et cetera. It may even be more than 50%, but I'm
a strong advocate of architects who still read and preferably also write
code.
See also Gerrit Muller's web site. The front page of his PhD thesis shows a system architect as a multi headed creature, illustrating the many aspects that the architect must offer. The ugliest head is his (no, just kidding :-). Especially interesting may be the section on the System Architect as a Person.
Post Script: why do I believe that architects should also code? Well, it's not really that they should write 10% of the code, but I know many software architects in my organization who even never look into the code, and thus are not confronted with the consequences of their architectural decisions.
There is a second argument: I believe that we can only build dependable systems if we create a skeleton (some would call it a framework) of high quality code, in which components 'plug-in', and that guard the system from failing when individual components fail. Such a skeleton could typically be developed by an architect or chief designer.
1. See sheet 44 of
my
presentation.
2.
Paul Clements,
Len Bass,
Rick Kazman.
3. See chapter 8 of my
PhD thesis.
(c) 2005, Rob van Ommering, November 9, 2005, minor updates on December 2, 2005.