This is the governing body for certification in Disciplined Agile.
LIVE CHAT 24 HOURS PER DAY
(cross-cutting concerns - only a detail)
When we are building a new product, or when we have a major upgrade (of the product), the architecture of a component a fundamental aspect. We have made major products upgrades where the most of the components remain the same (forced move: one component represent an aspect of the usage), but the major architectural change is related to the interior of a component.
Ime the work related to the interior of a component could suppose hundreds of times more effort than identification of the high-level components. This part of the architecture could include the main decisions related to the separation of concerns, addressing some NFRs for each component, addressing cross-cutting concerns.
If I do not have a solution/architecture for each type of component, I have no solution, but just some drawings and concepts.
If I play the role of the product sponsor I will consider that the development team has a proven architecture only if they have proved each major type of components. IME this was the fundamental aspect that makes a solution approach valuable. I will deliver value by delivering components. I will continuously deliver components only if I have a solution for each component type. Just the list of the components is not the architecture, but only having also an architecture for each type of component.
Examples fro types of components:
I expect that the main cross-cutting concerns to be addressed for each type. Here are some of them that I would consider mandatory in architecture envisioning: error response, memory management, internationalization and localization, information security, logging
monitoring, exclusive access (locking). I saw too many problems created by these aspects, and now I expect architectures that will give a consistent approach.
I think we should not discrimnate between various dimensions of the architecture.
Business use cases to explore the architecture
Intro: The development aspects are interrelated, and a decision about requirements could affect the optimum about the solution approach (the optimum is about the whole, not about the parts).
A good architecture approach could explicitly represent the usage and decouple this usage from other aspects (easy to change). For example, we could use the functional criteria to create components.
We could also think to a very high-level TDD/validation, so the usage is a significant aspect of the architecture.
A more concrete example - software for a retail store. The main business cases in a day are
We could have two categories of factors: context forces (complexity, incertitude) and process improvement decisions (e.g., evolution to continuous delivery). If I need to enumerate the principal context forces that could influence the life-cycle selection I will pick:
@Jerry: Good point.
@Edson: This goal is within the scope of Inception, which would be an extension of a "Design sprint" I suppose.
All: We hope to get an updated excerpt published in the next day or so. As you can see we have a fair number of great ideas to act on!
Hi folks, Identify Initial Architecture Strategy-> Apply Modeling Strategy(ies)
I suggest applying "Design Sprint" as an approach to model the initial solution and User Interface Needs as well.
In investigating legacy assets - we have found that establishing whether a legacy asset has API's or not helps with forming a strategy on architectural solutions. Sometimes having a roadmap for legacy assets to expose their data via API as an enabler to product delivery is a strong consideration when determining a MVP, for example, would not probably integrate with a legacy asset on a first release of a mobile solution but would ensure that that a roadmap was put in place to ensure that the legacy asset was reviewed or opened up such that at a future point in time such integration was possible without creating unnecessary bottlenecks and key dependencies.
Identify Initial Architecture Strategy – Reasons: complement Initial Scope
Another significant reason to identify Initial Architecture early is to complement identifying Initial Scope earlier: these aspects could never be investigated separately and will be more iterations. Investigation solutions (and consequences) could trigger, for example, scope clarifications and negotiation.
Identify Initial Architecture Strategy – Reasons: life-cycle approach
Incertitude related to solution (and scope – I forgot to mention for that section) and possible solution delivery approach are the main decision points and factors to select a life-cycle approach
Identify Initial Architecture Strategy – explore by modeling & spiking
In the course diagrams for activities needed during the inception for both Architecture and Design, we could find Envisioning, Look Ahead Modeling but also Spikes. Every time when we need to invest more in modeling we should check if prototyping/spikes are also needed. Should be a normal approach that we do not need prototyping only for UI, but also for other solutions aspects. When we have high incertitude for some solutions aspects spikes could be one of the best options.
Here are some factors where spikes could be mentioned
Even some of the spikes could be realized during the Construction, and especially for Proven Architecture Milestone, we still need Spikes as an option during Inception. From my experience, the best engineers are using spikes early earlier and more often.
Identify Initial Architecture Strategy – Build from the scratch (crucial decision point)
It is very likely to be a high incertitude case – so we can need Spikes. More: here it is a very important decision point to use one of the ordinary Agile/Lean life cycles or Lean Explore Startup Life-Cycle.
Identify Initial Architecture Strategy - Explore Business Architecture: business use cases
Business use cases are a good option vs. classic BPM and have a much more reduced “impedance” difference versus solution modeling.
The list of options it is mainly related to “interfaces”, that will drive understanding for sub-systems components and inter-system decoupling and collaboration. A missing aspect is the one related to cross-cutting concerns. It is like we have most of “horizontal” architectural views, but we do not have enough about “vertical” views. A major decision related to architecture is how will be built a component and sometimes is far more difficult than deciding which will be the components (that could be domain-driven). Too often inexperienced teams and developers consider that this aspect it is a detail and not architectural. In my experience 80% of the architectural effort (concept and proving) it is related to the internal architecture of the component (or component types).
So, level of details should have at least these aspects:
Note: for internal architecture of the components we could also use interfaces, but that is just an intention that needs to be proved. The internal architecture of the component it is a decision with long-term consequences – so it is never trivial.
Many Agile knowledge sources about architecture are referring mostly this internal architecture as Jim Coplien Lean Architecture, Uncle Bob Clean Architecture or Universal Design Pattern by Koni Buhrer from Rational.
I have just published an update to the excerpt where I've added a decision point to Investigate Legacy Assets.
This is something long in coming, IMO.
Klaas, interesting point. I will think about that a bit. Perhaps the issue is that there is a missing decision point around exploring the existing architecture. Basically do some archeological exploration in your case.
© 2013-2019 Project Management Institute, Inc.
14 Campus BoulevardNewtown Square, PA 19073-3299 USA