Agilists and architects too often talk past each other. In this issue’s “The Pragmatic Designer,” guest columnist Eltjo Poort helps to bridge the divide by identifying five architecture responsibilities. This enables teams to introspect about how well they are handling each, and encourages them to avoid the extremes.
A bit of planning is indispensable to anticipate events that will affect your software’s risk profile. Traditional architectural planning emphasizes the spatial dimension (for example, components and connectors) but neglects the time dimension. Consulting IT architect Eltjo Poort makes the case for an explicit representation of architectural evolution along the time axis and reports on the experiences with architecture roadmapping where he works.
‘The best architectures, requirements and designs emerge from self-organizing teams’, is wellicht het meest misbruikte principe uit het Agile Manifesto. Door de jaren heen was de gangbare interpretatie van dit principe verworden tot: ‘Hoe minder je nadenkt over de toekomst, hoe beter je systeem wordt.” Het was de afgelopen tien jaar in de software-ontwikkeling niet bon-ton om het over architectuur te hebben. Maar het tij is langzaam aan het keren.
Modelleren wordt weer oogluikend toegestaan – zij het soms achter gesloten deuren, om het stigma ‘Big Up-front Design’ te vermijden. We durven het nog nauwelijks hardop architectuur te noemen, dus ontstaan er eufemismen als ‘Design thinking’ en ‘Master builder’. Maar het besef dat een beetje anticipatie in je systeemontwerp noodzakelijk is om risico’s beheersbaar te houden is nu wel doorgedrongen, getuige bijvoorbeeld het concept van de ‘Architectural Runway’ in het steeds populairder wordende Scaled Agile Framework.
Het is dus weer veilig voor ons, de anticiperende ontwerpers in de digitale wereld, om voorzichtig uit de kast te komen en ons bekend te maken als bijvoorbeeld enterprise-architect, solution-architect of software-architect. Daarmee is het ook tijd om de balans op te maken: wat staat ons te wachten, wat speelt er in het land van de digitale architectuur? In dit artikel een korte inventarisatie van de belangrijkste trends en ontwikkelingen.
Organizations require cost estimates for delivering and operating software-intensive solutions. One of the factors impacting these costs is the solution’s architecture. Applying solution architecting practices helps improve the accuracy of early cost estimating. In CGI, we have started to emphasize the application of architecting practices in cost estimating, and this paper reports on the early experiences of this initiative, which we call Solution-Based Estimating. We present an architectural viewpoint designed to address the costing concern, and report some early feedback from projects that have applied the Solution-Based Estimating approach.
Five pieces of advice can help architects become more effective in an agile world without having to implement new methods or frameworks. They describe changes in attitude or behavior rather than complete practices or principles so they’re easy to digest and apply.
Free version (Computing Now)
Agreement on Non-Functional Requirements between customer and supplier is crucial to a successful IT solution delivery project. In an ideal world, stakeholders and architects cooperate to achieve their common goals in a win-win situation. In a commercial setting, however, one dominant feature often introduces powerful forces from outside the technical realm. That feature is the customer/supplier relationship, usually formalized in bidding rules or as a delivery contract. Formal customer/supplier relationships often place severe limitations on information exchange between stakeholders and architects. In this paper, we explore the effect of such limitations on the interaction of architectural design with the quantification of Non-Functional Requirements, and explore a number of avenues to deal with them.
This paper appears as chapter 3 in Improving Solution Architecting Practices
We propose to view architecting as a risk- and cost management discipline. This point of view helps architects identify the key concerns to address in their decision making, by providing a simple, relatively objective way to assess architectural significance. It also helps business stakeholders to align the architect’s activities and results with their own goals. We examine the consequences of this point of view on the architecture process. The point of view is the basis of RCDA, the Risk- and Cost Driven Architecture approach. So far, more than 150 architects have received RCDA training. For a majority of the trainees, RCDA has a significant positive impact on their architecting work. This is an extended version of the WICSA 2011 paper “Architecting as a Risk- and Cost Management Discipline“.
This paper appears as chapter 9 in Improving Solution Architecting Practices
As the presence of Information Technology increases, so grows the impact of the design decisions shaping the IT solutions that touch our lives. Solution architecting is the art of making such decisions – a relatively new craft emerging in the IT industry. We see the value of modern IT solutions in their rich functionality, but most of the risk and cost of delivering these solutions are driven by the other, “non-functional” aspects.
This thesis relates the story of the development of practices to address these non-functional aspects in solution architectures in Logica. It presents the research that eventually led to Risk- and Cost Driven Architecture (RCDA), a set of principles and practices that guide architects in designing and delivering solutions.
This paper presents the analysis and key findings of a survey about dealing with non-functional requirements (NFRs) among architects. We find that, as long as the architect is aware of the importance of NFRs, they do not adversely affect project success, with one exception: highly business critical modifiability tends to be detrimental to project success, even when the architect is aware of it. IT projects where modifiability is perceived to have low business criticality lead to consistently high customer satisfaction. Our conclusion is that modifiability deserves more attention than it is getting now, especially because in general it is quantified and verified considerably less than other NFRs. Furthermore, IT projects that applied NFR verification techniques relatively early in development were more successful on average than IT projects that did not apply verification techniques (or applied it relatively late in development).
This paper appears as chapter 4 in Improving Solution Architecting Practices
Architectuur is te beschouwen als een discipline die gedreven wordt door risico’s en kosten. Risico- en kostenmanagement is dan het primaire businessdoel van het architectuurproces. Dit gedachtegoed vormt de basis van een aanpak voor solution architecture die bij Logica is ontwikkeld, getiteld Risk and Cost Driven Architecture (RCDA). De auteurs beschrijven de achtergrond van deze visie en de impact ervan op het werk van de architect.