In Beyond Software Architecture, Luke Hohmann addresses all things paramount to software product development that are usually not covered in books on software development. These things include licensing, software protection, branding, marketing and business plans and how they relate to the technical architecture and more. Every developer or architect that has been around a few projects probably will probably recognize the importance of some, if not all of these areas, in relation to creating and sustaining a winning solution.
The first and probably most important topic covered is the relation between the business model and the technical architecture. It is really an understatement to claim that the chosen business model has a serious and real impact on the technical architecture – it should be self evident that there the architecture will look quite different in an ASP scenario and a single user desktop application… Less self evident is the relation between the business plan and the technical architecture. What business segments are being targeted and in which order really does bear on the architecture. Each business segment will have its particular needs to be addressed as features in the software solution. The order is important since it will help spell out the technical roadmap for future releases.
The book covers a large number of topics and gives advice on a number of specific issues, too many to cover here. I have chosen but a few that have stuck after finishing the book.
Marketecture
The relation between development and business is generally acknowledged to be difficult and fraught with miscommunication and misalignment of goals. There are many books and methods addressing this gap between IT and business. Hohmann contribution to closing this gap is to distinguish between what he refers to as the Marketecture and the Tarchitecture. The Tarchitecture is short for technical architecture and its definition is similar to what other refer to as system or application architecture, i.e. it covers things like components and their relations, which patterns are used for what parts of the application, technologies, platforms and so forth. The Marketecture should contain all things related to the business side of the system or application. This includes business segments, the business model and plan, user manuals, marketing materials etc.
Closely related to the two architectures are the corresponding roles, the Marketect and the Tarchitect. The Marketect role is usually shouldered by the product owner, business manager or similar whereas the Tarchitect is the traditional systems or application architect or perhaps in some cases an IT-manager. It is rare for the two roles to be handled by the same person since the two perspectives can be difficult for one person to manage simultaneously.
The Marketect and Tarchitect should work closely together to create the Marketecture and the Tarchitecture. This is of course easier said than done, but to me the value of Hohmann’s definitions is primary in making the Marketecture needs visible. Coming from the IT-side, I believe this too often be neglected by the business side and often poorly understood by development.
Capabilities versus features
A minor point made by Hohmann (and perhaps trivial to many architects but enlightening to me) is the difference between a systems capabilities and features. The system’s capabilities are all the functionality made possible by a certain technical architecture whereas the systems features are the features actually implemented. Implementing a feature where the system lacks the capability means changing the underlying architecture. To me this seems different from the anti-pattern designing for the future. A good architecture has relevant capabilities making implementing the desired features easy, but this does not mean that a lot of time has been spent on implementing features that are not needed. It simply means that sound architectural choices have been made creating a sound system. This could be a fine line, however, since making constraining choices that limits the system’s capability, are sometimes necessary.
Release checklist
In appendix 1 a release checklist is found, summarizing the many of the core concepts in the book. This checklist seems like a sound thing to run through not only before each release, but also at the start of a development effort. Running through the list just prior to a release it may be too late to take care of things missed i.e. it will incur what can be referred to as a technological debt (a term used in the book but first defined by Ward Cunningham). Incurring a technological debt means that the development team will have to work harder in the next release to fix the things missed in the previous release and that quality suffers.
Patterns
The book sports A Pattern Language for Strategic Product Management found in the appendix. This pattern language defines common problems related to product development and proposes simple solutions. More thorough descriptions of the problems and the proposed solutions can be found in the beginning of the book.
| Pattern | Problem | Solution |
|---|---|---|
| Market Map | How do you segment your market? | Create a visual representation of the market(s) you are targeting |
| Market Events or Market Rhythms | What is the right frame of reference for time in your problem domain? | Identify the events and rhythms of your market/markets segments |
| Feature/Benefits map | How do you ensure that the right features and benefits are being created for your target market(s)? | Create a map of the proposed features and their benefits. Tie these to the market(s) you are targeting. |
| Tarchitecture Roadmap | How do you manage the evolution of your technical architecture? | Create a roadmap of know technology trends. Include specific and well-known changes you want to make to your architecture so that everyone can plan for them |
Usability
Hohmann addresses usability in a chapter of its own. Usability in this context goes beyond user interface design and has a deeper, structural meaning. He stresses the need of a good metaphor that should permeate the whole architecture. This is reminiscent of the thoughts behind Domain Driven Design, though this is not mentioned in the book. A usable application or system should cater to the real users as found in each market segment. An application sold to two different segments may be very usable to one, but not to another. Consider for example an application that targets both an expert and amateur segment. Helpful wizards that guides the user through difficult steps may be very useful to the amateur but not to the expert or power user.
Summary
Beyond Software Architecture is a good read for architects and developers who wish to expand their view on Software architecture and development. It succeeds in addressing issues often neglected elsewhere in literature on software development. As with many more high level books, however, I believe the business side to benefit most from this book. A better understanding on the business choices and their technical consequences is often needed and the need for seriously addressing the business and technological should be recognized.