Monday, June 30, 2003

When to re-architect?   Luke Hofmann in his book “Beyond Software Architecture” gives a rule of thumb as to when to consider changing the architecture. The rule says that that says that you should consider the venture if the re-architecture would take half of your current team working for 1 year.   I would approach giving the answer this question a bit differently. You should consider re-architecting every time one of the success factors of the architecture isn’t working for you. Any one of the points in the section “Why architecture matters” (plus the platform factor) should be considered as alarm bell.   To give a real-life example, a large scale 3D production system had to be re-architected because several of the success factors have seized to be true. Here are examples of some of those factors. The old architecture made it difficult to change things customers wanted changed. The old architecture has lost its unfair advantage the system enjoyed over the years. There was also the platform factor. The platform the system ran on didn’t match with the changing realities of the marketplace. Support the aging platform was to run the risk of killing all revenues from the product. The decision to re-architect was the right one. In fact, it should have been taken earlier. It took most of the development team to re-architect the system over the 4 years of development. Through this time, a small development group was tasked with maintaining the old system.   Another example from a software company in business of developing online security services for consumers. While current architecture powered their product, the decision to re-architect was taken after it became apparent several success factors weren’t stacked in their favor. Looking at costs of sustaining current architecture it became clear that the system need to be more profitable architecture. The profitability factor is closely related to the cost of changes. The management realized that is would be too costly to attempt to execute the product roadmap on the current architecture. In order words, the feature customers wanted were just too difficult to implement. Then there was the platform factor. The old architecture was using a collection of open source pieces (ex: MySQL database) that were difficult to keep in the context of all the new features customers were asking. In this case, the decision to re-architect was taken even though it will impact the entire development team, even require bringing new talent.      The book “Beyond Software Architecture” by Luke Hofmann provides a good answer to this question of why software architecture matters and essentially enumerates the success factors of architecture: -         Longevity. The architecture will outlast most of the code, and can even sometimes survive changes in business models. -         Stability. You cannot claim you have architecture unless it is stable. -         Degree and nature to change. The architecture should successfully respond to changes to things like functionality, priorities of different feature sets. -         Profitability. The architecture is successful when its profitable. -         Social Structure. The architecture fits well with people who work with it. -         Boundaries defined. The architecture that clearly defines what “in” or “out”. What kind of extensibility is supported or not.   (The book also includes sustainable, unfair advantage as created by product architecture. I disagree that a successful architecture must present an unfair advantage or be hard to duplicate. At times, the unfair advantage of the business model could indeed be based on the architecture, but oftentimes successful businesses are based on classic well-known architectures.)   After reading though the list of success factors I was tempted to add one more. The Platform Architecture isn’t created in the vacuum and will always be based on some platform. A platform could be an OS, a database server, a runtime (Java Virtual Machine or .NET Common Language Runtime) or other foundation pieces. Even if you successfully define the boundaries of your system, the will be critical pieces that would fall outside of your architecture. Any non-trivial architecture benefits from numerous services of the platform. Once the platform is picked, its evolution will most likely be outside of your control. Because of the longevity of the architecture, you will often want the system to run on newer versions of the platform to come long after you’ve completed the architecture. The platform will always have the ability to ultimately kill the system or sustain it over the long run.      Beyond Software Architecture by Luke Hohmann. I bought this book based on several factors. First of all, I think that learning more about interrelationships between marketing and software engineering should be important for anyone interested in creating successful software products. Secondly, I’ve found that the first book in AW Martin Fowler Signature Series (Patterns of Enterprise Application Architecture) a must-have reference for every serious software architect. When I first opened this book I was very impressed by the number of high-profile people endorsing it and giving it praise. Exited, I’ve said to myself and others that I have great expectations for this book – I will learn a great deal from unique experience of the author. After all, not every author can speak from the position of software architect, product manager, marketing professional, software developer, development manager, consultant and teacher.   When I started reading, I began to notice that statements made by the author were correct, but often too simplistic, trivial or incomplete. Not to worry – I though to myself. The author must be preparing the reader for in-depth insight on “how to build winning solutions”. So I’ve continued reading.   By the third of the book I’ve stopped taking this thing seriously. I’ve realized that the author has chosen to touch on every single topic relevant to a software development organization. The trouble is, the author fails to tell anything that would not be considered trivial by any experienced software professional. Opening the book at random you’d stumble on sentences such as “The business plan distinguishes itself from all other development documents at it is the foundation for all the work associated with the product.” Correct, but fairly content-free.   And then, there are numerous text boxes that break-up the prose by telling a story from author’s experience. Most of those stories tell about how the author single-handedly saved the day by being super clever, super insightful and generally super smart. Great stuff for someone who considers hiring the author, but most of those examples bring little in terms of in-depth analysis of the issue.   The bottom line is, if you’ve spend a few years developing commercial software – don’t bother reading this book, you probably already know the things this book talks about. And if not, you’ll be much better off picking a more focused book that covers a particular topic of interest. Would I recommend this book to a student? No. In fact, the book is even less useful for a student because it covers too broad of an area without giving the reader in-depth knowledge in anything. Perhaps the only case where the book would be useful is for someone who wants a high-level overview of the issues that architects, senior developers and product managers worry about.   One good thing that this book introduces (in appendix) is the idea of using patters for things beyond software design. The idea of capturing “design patterns” for business and marketing issues isn’t new, but definitely not completely explored or understood.   The book attempts to close the gap between business and technology. Not many people have had the right experience to do so and be able to write well about it. The best (even a bit dated) book I’ve read on the subject remains “High-Tech Ventures” by Gordon Bell.      You are Neo, from "The Matrix." You display a perfect fusion of heroism and compassion. What Matrix Persona Are You? brought to you by Quizilla [via TheArchitect]

Site Statistics

© Copyright 2003 Alexis Smirnov. Last update: 9/8/2003; 1:53:12 PM.