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.
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