Home  Articles Articles Software Architecture Challenges and Significance in an Agile World
|
Software Architecture Challenges and Significance in an Agile World |
|
|
|
|
Written by Peter Hodgkins
|
|
Tuesday, 08 April 2008 |
 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.
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).
Figure 1: Simplified product roadmap
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.
Comments () |
 |
|
|
|
Tags:
Click to add your tags...,
|
|
|
Latest Issues of Agile Journal
Coming Up - Editorial Calendar
- August 13 - Quality Agile Development
- September 10 - Agile News
- October 08 - Valuable Agile Practices
- November 12 - Introducing Agile to the Organization
- December 10 - The State of the Agile Community
See the full 2008 Editorial Calendar >
|
