Uncategorized Is solution architecture compatible with agile? – BCS
BCS MEMBERSHIP
Join the global and diverse home for digital, technical and IT professionals.
CHARTERED IT PROFESSIONAL
CITP is the independent standard of competence and professionalism in the technology industry.
APPRENTICESHIPS
Work in an exciting technology role and train at the same time, with a digital apprenticeship.
CONTINUING PROFESSIONAL DEVELOPMENT
Raising the standards of competence and conduct across the industry.
IT SKILLS FRAMEWORK (SFIAPLUS)
Understand your skills and your next steps.
SOFTWARE TESTING CERTIFICATION
Over 100,000 professionals worldwide are certified with BCS.
ESSENTIAL DIGITAL SKILLS
Improve your digital skills so you can get on in today's workplace.
EVENTS CALENDAR
View all of our upcoming events.
ARTICLES, OPINION AND RESEARCH
The latest insights, ideas and perspectives.
IN FOCUS
BCS MEMBERSHIP
CHARTERED IT PROFESSIONAL
APPRENTICESHIPS
CONTINUING PROFESSIONAL DEVELOPMENT
IT SKILLS FRAMEWORK (SFIAPLUS)
SOFTWARE TESTING CERTIFICATION
ESSENTIAL DIGITAL SKILLS
EVENTS CALENDAR
ARTICLES, OPINION AND RESEARCH
IN FOCUS
21 January 2022
Big design up front is anathema to many agile aficionados, so how can solution architecture and agile work together successfully? Mark Lovatt, Deputy Chief Examiner for Solution Development BCS, explores.
Agile software development methods emerged in the 1990s as a reaction to the failure of waterfall which was too slow with too much regulation, planning, micromanagement and documentation. Waterfall, it seemed, moved so slowly that by the time any software was released, the customer needs had moved on – and so had the business environment.
The Agile Manifesto[1] was produced in 2001 to bring together some of the main principles common amongst Scrum[2], XP[3], DSDM[4], UP[5] and others by their A-list proponents during a legendary weekend at a ski resort in Utah. The manifesto is typically light on documentation, containing only 68 words and is a statement of belief rather than a methodology in itself. The core is a mere 24 words:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
In 2001, solution architecture was not a big part of the conversation among many software development practitioners. Architecture frameworks, such as Zachman[6] and TOGAF[7], and standards such as ISO 42010[8] were available but were mainly of interest to industry giants. However, interest among all organisations has grown exponentially in the last 20 years – perhaps, in part, as a reaction to the perceived failings of agile, aka ‘fragile’, to deliver what the business needs in a sustainable way.
Solution architecture, like agile, has traction because of deficiencies in existing methods of solving problems purely with software, predominantly where the focus is too narrow or localised to be fully integrated. This is separate from the heavy vs lightweight battle addressed by agile.
Solution architecture is holistic both in its approach to identifying problems, risks and opportunities and in producing high level, component-based designs that integrate with the business in its current state and flex over the medium term as strategy and environment dictate. Software alone is rarely the solution. Even pure tech companies need people and other aspects of the real world to succeed.
What solution architecture brings to the table is a way to avoid unforeseen side effects and dead-end changes, both of which are unfortunately possible even when using agile.
Ok, there is a lifecycle with processes, tools and techniques[9] but these are simply there to facilitate and strengthen interactions between individuals, especially customers.
Documentation is minimal and just-in-time, with nothing being prepared before it is needed and with just enough detail to move forward. Solution architecture does not deliver software but it does produce working designs that act as a blueprint for change and integration.
Contracts are not used in solution architecture; rather, customers have the power to approve and make changes to designs at all stages. Even the final design does not dictate a fixed plan for delivery but rather a roadmap that works with agile (especially Scrum) or any methodology that is deemed appropriate – even waterfall!
Yes, it is based on an evolutionary cycle that allows for trial and error, with fast failure for designs that don’t work for customers or have too much cost or negative impact.
The main overlap is the roadmap which provides the interface between design and delivery-solution architecture provides the design and agile is the methodology for delivery. Whenever a roadmap is required, solution architecture can be used to build it.
Most agile teams speak about the delivery of a product based on a roadmap which informs the product backlog. The use of the term ‘product’ is being gradually superseded by ‘solution’ which covers products, services and combinations of the two.
An agile roadmap is a ‘schedule of events and milestones, according to SAFe[10] so the business can see what it is getting and when. In addition to providing a reliable method for producing the roadmap, solution architecture links the deliverables and benefits that the business understands, directly to the solution components that enable them, therefore acting as a fulcrum between business and technical change. Any future changes to the roadmap can be instantly linked to the design and vice-versa, with impacts easily identifiable in both directions.
The slightly surprising answer is ‘no’. There are at least two scenarios where agile should go it alone. One is where the situation is simple and the solution obvious. Agile can quickly make a change for the better and there are unlikely to be knock-on effects on the rest of the business.
For you
Be part of something bigger, join the Chartered Institute for IT.
At the other end of the scale, the situation may be so complex that a component model can’t get to the bottom of it. This involves much more risk but agile can be used to make small, incremental changes, based on the judgement of business leaders – and then assess the outcome of each change – before deciding how to progress.
The sweet spot for solution architecture with agile is in the 80% of cases where a business needs positively transformative change delivered in the short term, with a progressive roadmap for the medium-to-long term.
Well of course the future’s always hard to predict but the recent direction of travel has been inexorably towards the business having more control over business and IT change. That could mean strategic tools such as those of solution architecture becoming more widely used, depending on the culture and appetite for risk within the organisation. Frameworks such as SAFe emphasise the need for business solutions to follow strategic themes within an overall portfolio vision, without specifying how this is to be achieved. Solution architecture can be used to capture the business vision and design one or several solutions around it.
There are a few possible reasons such as the general lack of knowledge of the subject within the development community, meaning the demand isn’t there. On the supply side, universities and colleges are quite conservative about introducing new topics into courses, especially at undergraduate level. Then, there is the question of where such a topic would fit in: would it be better as a final year undergraduate module, part of a master’s degree, or fully integrated throughout?
This is a debate that has been going on at BCS relating to the restructuring of the solution development diploma. In the industry, architecture has been seen as an advanced area, with the term being added to job roles to make them a promotion from lower grades. It seems that everyone wants to be an architect these days!
Many think that solution architecture is something you can only do after years of toiling as a developer, tester or other entry level team role. Even if this were true, the design focus of solution architecture is surely something that all team players would benefit from knowing something about. After all, IT undergraduates learn about all roles – from coding to project management.
A more radical and ‘architectural’ way of thinking might put solution architecture at the core of all the other disciplines of solution development. Developers, data designers, business analysts, change managers, security specialists and others are ultimately producing components that must integrate with each other and the operating environment. The components and their interfaces are the stuff that test plans and scrips are made of. This analysis would suggest that solution architecture should be fully integrated into undergraduate degrees with possible future advanced study pathways, rather than as a ‘bolt on’ to existing courses.
A good starting point would be the recently published BCS book, Solution Architecture Foundations[9] in which the author, Mark Lovatt, covers the subject in a comprehensive and accessible way with links to other useful resources. It is available now from the BCS Bookshop.
Mark Lovatt is Deputy Chief Examiner for Solution Development for BCS, The Chartered Institute for IT and Director of Mark Lovatt Associates providing specialist services in enterprise, data and solution architecture, and software development.
11 minutes ago
6 days ago
6 days ago
