At the core of all software solutions are underlying software architectures. The architectures reflect initial assumptions about how products fit together, which features are of value to customers, what are the expected integration points, with which related technologies. As software products find acceptance among customers, and technologies continue to evolve, the creators (vendors) of these solutions eventually find the need to adapt underlying architectures. Agile provides a means of doing this early in the product lifecycle and with continual review that provides the creator with the ability to adapt quickly and effectively to changes is the marketplace.
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.
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.
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