Major changes to software architecture can be complex, expensive, and hard to deliver on time. Some software companies ignore the need for architectural change entirely, while others dramatically underestimate the magnitude of the work. Typically, the results of deferred architectural improvements are major technical "show stoppers" that block the launch of new products and enhancements.
Agile has some unique ways of approaching architecture change that are increasingly accepted as Agile matures and is widely adopted.
Agile Matures
When it was first conceived, Agile was exclusively viewed as a development model, changing the inner workings of software creation to address traditionally ineffective and inefficient approaches. Customer input and business strategy were initially considered as external inputs from the development organization and as such were not well integrated into the development of products. It was into this development focused landscape that Scrum and Sprint were born, with a focus on Extreme Programming and other engineer-centric improvements. Product management and non-development executives had not yet been invited to become deeply engaged in Agile issues.
With repeated and dramatic results from the development side, Agile now has a broader place in today's technology/business world. Many businesses now see (and practice) Agile as a product development methodology from project inception to delivery, ongoing product support, and end-of-life. With a much longer time horizon, software architecture becomes even more important: real products, delivered for revenue to live customers, need to be built on a solid foundation that can anticipate changes in customer needs and shifts in the technical environment. Longer lifetimes for Agile products drive us to be more thoughtful and more "plan-ful" about architecture.
Architecture Matures
As we had earlier discovered with more traditional development methodologies, architecture matters. It is integral in the successful delivery of a software product and those who fail to grasp this leave themselves open to failure as the underlying design cannot support the product. More importantly, Agile's maturity from short-duration lab projects to strategic development efforts underlines this importance. The very definition of architecture has evolved to become Tarchitecture (Technical Architecture) and covers not just software architecture, but hardware architecture, hosting approaches, and the business support models for products being developed and marketed. Agile has also evolved from small co-located teams to large organizations spanning time zones and international boundaries. The scale and scope of Agile projects makes them more likely to need technical architectural changes.
So how does a business adapt to Tarchitecture in this new world?
Adapting to Tarchitecture starts with a recognition that drivers for change usually come from outside the development team. Demands that force adaptations of the underlying architecture are frequent and customer-driven: expanded feature requests, competitors' announcements, new mobile platforms, evolution of business models toward pay-per-use and advertising-based revenue, multi-tenancy replacing single-copy customer installations, newly acquired business partners needing back-office integration, radical drops in the cost of storage and bandwidth, etc. Development teams look to Product Managers to force priorities onto this situation, mediating between a chaotic world and an energetic engineering organization with backlogs and user stories as artifacts of those priorities. Equally important, the development organization looks to its Architects to build structures that allow easy adaptation to a selected range of future opportunities. This combination of Product Management and Architecture lets the broader team move ahead - confident that they can stay Agile as events unfold.
Product Management and Tarchitecture
Product Management (and Product Marketing) are the owners of the product, and are therefore responsible for its direction and evolution to serve its marketplace. Product Management must plan out the next 18 to 24 months, identifying what the product will look like and creating a roadmap. It is critical for software architects to be part of this long-term planning. Architects have a "seat at the table" precisely because they help define what can be done, how seemingly unlike requirements can be combined, and how the product will need to evolve over time. Participating in scenario planning for the product is a great way of understanding likely changes that could emerge later.
Consider a traditional roadmap that shows how the product will be enhanced and evolved over time. It identifies the handful of features which product management believes will "move the revenue needle" as well as the broader set of features and benefits that the business desires. Significant market data and delivery timeframes (as called out by the business unit) are shared with stakeholdersin the product.
Our experience is that the roadmapping process is much more powerful and has more actionable results when the Architects (software, hardware, and support) are part of the roadmapping team led by Product Marketing and Management. They are able to identify key Tarchitectural changes up front, and when those changes will be needed to meet specific goals and delivery dates. Having this information at the earliest planning stage (i.e., during strategic planning) and not just when moving items from backlog into development, dramatically improves the product itself by allowing stakeholders to anticipate changes and incorporate key design improvements that may otherwise be overlooked or that are not developed due to time constraints of finding out about architectural issues so late in the design and build process. This is not to say that architect/product management teams will identify every detail of Tarchitectural change, but that good analysis and planning can provide a competitive edge.
Let us take a theoretical example and show it graphically (see Figure 1).
This simplified roadmap shows the plan for a "small office upgrade" to an existing offering. The target delivery is in Q1 of 2009. A key benefit of this offering is that the vendor can run it as a managed service, simplifying sales and deployment for customers. Since we are including the Tarchitecture group (architects and product managers) early in the planning process, they have identified "managed service" as a component that must be completed before product launch, in Q4 2008. More specifically, a move to a LINUX platform is a key technical requirement for this service element, and must be finished in Q3 of 2008 to keep on schedule. Using this roadmap, the team can then determine if delivery dates are possible (and at what staffing levels) in order to meet the business objectives. Excluding architects from this early discussion will typically mean the roadmap needs to be reworked several times or will be incorrect in its delivery date predictions, since it lacks critical input from key technologists.
This approach may also enable smarter architectural choices. Since the architects can see ahead four to eight quarters, they can anticipate some of the "surprises" which used to pop up - and design accordingly. A typical example would be the need to significantly change an underlying database's design structure, something that without architectural input may not be apparent until development begins. They can also spot technology-based opportunities that naturally fall out of their designs. In this case, for instance, they might see opportunities across projects ("there's another group building web services tools that we could use..."), for hardware platform savings ("since we're migrating to LINUX, we could virtualize some old systems and reduce overhead..."), business models ("we could easily include try-and-buy downloads, which you were asking about last month..."), design choices ("we will need different encryption versions for domestic and international use...") and other kinds of insights that may not be obvious to less technical reviewers. Introducing Tarchitects early in the product lifecycle provides maximum leverage for their expertise, and is a key factor in creating a durable product architecture. Consider the potential business impact to your own business of including Tarchitects early in your roadmapping.
Tarchitecture as a Product In It's Own Right
What else can we do to aid with the Tarchitecture evolution?
As the Agile methodology moves from mapping of products into the features that will be created in the backlog and constructed in the development and engineering phases, we can treat Tarchitectural needs as products to gain that technical architecture edge.
In this ever diversifying world of teams being spread across continents, organizations should make Tarchitecture groups products in their own right. Software Architecture, Physical Architecture, and Support Organizations are organic parts of a business. They may not be recognized as serving the customer or market directly, but if they are not given a voice in the planning phases and dedicated time in the development phases, eventually the infrastructure that supports a product will become obsolete. This will result in the underlying infrastructure being all the more difficult to bring back into line to provide the needed support for the product. This can, in extreme cases, lead to a ‘freezing' of new product or product enhancements whilst major reworks in the Tarchitecture environments occurs. It is far better to consider Tachitecture as a product set in its own right and develop it in each release, the "something for everyone' release theory.
Tarchitecture and Quality
Another area where businesses can take advantage of Tarchitecture to manage change is through the use of quality levels.
What is a quality level?
Quality levels are a set of agreed upon business and technical attributes that are applied to the Tarchitecture with known consequences. A consequence may be to make the conscious decision to delay instigating redundancy in an architecture to meet a business delivery date or remove certain Tarchitectural features to meet certain business criteria. What makes using quality levels viable and desirable is that the entire business is aware of both the actual decision and its ramifications as well as the further plans required for delivering the entire architecture. This can be an extremely powerful tool for striking a balance between what a Tarchitect sees as the perfect solution and the business need to deliver. When used as a tool for integrating such decisions back into the roadmap, allowing displaced functions and their effect on later releases to be shown, the business is building an iterative, agile, approach to Tarchitecture development.
Tarchitectural Models
Tarchitecture is a new idea, architecture is not. A business that utilizes already available architectural models and adapts them will reap both cost and time savings that can be significant. Twenty years ago, development organizations and businesses were building new architecture models, be they software, hardware, or support. Today, it makes far more sense to collaborate and adapt than build from scratch.
Tarchitecture: In conclusion.
In conclusion, Tarchitecture is Agile's answer to architecture, covering not only software architecture, but also physical and support architectures. To be successful in the new Tarchitecture world, Agile teams must foster collaboration, bring architects into the life cycle much earlier, and let them share ideas/observations throughout the product lifecycle. The results are not only better-architected products, but also the uncovering of new business opportunities hidden within that architecture.
About the Author
Peter has more than 15 years of technology and program leadership to Enthiosys, where he is responsible for the firm's strategic Roadmapping practice. He is one of the first industry experts to implement and manage multi-project / multi-location agile program management, including the creation roadmaps-of-roadmaps for complex division-level planning.
Most recently, Peter was a senior manager at VeriSign, where he led that company's worldwide Engineering Project Management Initiative. This included leadership for cross-functional multinational project teams, and pioneering techniques for coordinating agile software development across many time zones. In this role, he defined and deployed agile methodologies that reduced development time by 30%. Peter was also head of VeriSign's Agilist Group.
Earlier, he was Director of Client Engagements at Telefónica Data in Miami, a division of the world's sixth largest telecom carrier, and was Chief Technology Officer for Access International (Cambridge, MA). He started his career in the UK, working on information systems at Sporting Index Holdings plc and Duckhams Oils, a subsidiary of BP Amoco.
Peter's repeated successes on the front lines of software development and corporate IT have earned him the admiration of his colleagues on both sides of the Atlantic. His advice and experience are frequently sought. As a mentor and instructor, he is helping train the current generation of agile product/program/development managers.
Peter earned a Post-Graduate Diploma (Master's Degree) in Information Technology from De Montford University (Leicester, UK) and a degree in Electrical and Electronic Engineering from Nottingham Trent University.
