There is a high degree of confusion between the concepts of agile and enterprise architecture. The roots of the confusion are that most “enterprise architects” are not doing enterprise architecture. Fewer Agile Practitioners are actually doing Agile Development.
In our Consulting practice we constantly run into the most senior technical person being called an “Architect.” Worse, if they work on anything beyond a single project, they get called an “Enterprise Architect.” Everyone who holds a scrum, or any other regular coordination activity, claims they’re doing agile development. It has gotten so bad that there are actual guidelines on how to tell when it’s “Agile BS.” Perhaps one day we’ll get around to drafting guidelines on how to tell whether it’s “EA BS.”
EA Capability Document Download
|Essential documents to support establishing an EA Capability|
Good enterprise architecture delivers ahead of decision. Successful enterprise architecture delivers one of the four classic purposes:
- architecture to support strategy
- architecture to support portfolio
- architecture to support projects
- architecture to support solution delivery
There is no point in using the techniques of world-leading Enterprise Architecture if the practitioner is not ahead of decision or solving a complex problem. If the only thing on the table is rounding out the technical details or product selection, then the practices and overhead of good enterprise architecture are waste.
Putting “Enterprise Architecture” and “Agile Practices” together is straightforward. The first step is common to all method configuration-being crisp and clear about the problem that you’re solving. Aligning Agile and EA nets down to three basic models:
- Are you taking advantage of agile work practices to develop best-practice enterprise architecture?
- Are you taking advantage of good enterprise architecture to guide and constrain agile software development?
- Are you attempting to architect and agile enterprise?
While all three work together, there is no required association what so ever. TOGAF is an inherently agile method the central concepts of committing to doing useful work, incremental delivery, and iteration have been embedded in TOGAF since version 8. It is understandable that monster-project practitioners with years of waterfall development skipped over the text in TOGAF that speaks to iteration and latched on to the crop circle diagram of the ADM and read it as a waterfall process flow instead of the information model that it is.
This article is going to address the question are you taking advantage of good enterprise architecture to guide and constrain agile software development?
Supporting agile software development
Weak agile development practices hang everything off of the scrum, and the illusion that complex systems will arise by walking backward into the future. Strong agile software development practice understands the essential tension between knowing where you’re going, and not knowing how you’re going to get there. Unless we’re talking about a simple greenfield one-trick-pony organization the software products must fit into complex enterprise ecosystems. There are existing processes, organization, partners, and infrastructure enabling the business to serve its customers. The new “Product” must fit inside and enhance this ecosystem.
When you stop and consider the alignment of best practice EA and best practice agile software development for basic areas where they interact becomes apparent. Practitioners who work at the extremes of either Enterprise Architecture or agile software development may never know what the other person works for the company they may not see each other’s work product.
Consider an EA practitioner who is working to support strategy and a tech lead on agile software development team. The tech lead is focused entirely on an execution window measured in weeks or months. The really long term thinking will be tied to what can be called a release plan or even an architecture runway. On the other hand, the strategic EA practitioner could easily have been working several years before and laid out a roadmap to create the corporate capability of agile software development, or the outlines of the need that led to the definition of the project the tech lead is working on.
I had an amusing conversation with the newly hired Systems Reliability Engineer recently. The SRE specialist is all excited about our organization finally starting to follow modern practices force CI/CD. From her point of view she couldn’t see the work packages on the portfolio roadmap that brought our containers, test data management, and frankly laughably insufficient testing suite into existence. Nor did she realize that her job was funded because that same years old roadmap identified once we had the basics in place we would be in a position to up our game. I had to smile when she asked me what the EA Team was doing to help?
Good EA practitioners know that when she asked “what are you doing to help?” What she really meant was ‘what are you doing to help me today.’ The sad fact may be – nothing. EA team’s are created for a purpose and if we have been directed to serve strategy or portfolio we may not directly serve anyone working at solution delivery. In fact, a reasonable fraction of our work may be seen by bottom-up tactical solution delivery teams as hindering their time-to-market because we are insisting on specific integration patterns, tooling or security practices that protect a broader set of concerns.
When we design EA Teams to interact with agile we start at the same place for all EA Team Configuration what is the purpose this EA Team will serve: strategy, portfolio, project, or solution delivery?
Everything we do to design and configure an EA team is drawn from what questions does this EA teams exist to assist answering.
- First, defining the agile approach
- Second, guiding the backlog in Sprint
- Third, constraining the sprints
- Fourth, solving for cross product dependency
Define the agile approach
An EA Team that is serving Strategy and Portfolio will typically engage with Agile Software Development by defining the approach.
Products appear on a good roadmap as gaps, or work packages, on a roadmap will be the creation, reworking, or enhancing of different capabilities and their associated IT systems. It is common for these roadmaps to identify the need for new, or reworked, Products.
How Products, and other IT Elements, are supported or operated is a common directional question. Knowing whether we are building a new platform, using an Existing Platform, or Leverage in Third-Party Platforms As a Starting Point That Will Define Key Elements of Your Entire Agile Approach before You Start Coding. You Can Always Tell a Weaker Practitioner Because They Will Fixate on Attempting to Define Quotes on Platform. Quotes off crisp overly-precise definition is a trap many practitioners fall into it only takes a few second consideration to recognize that it’s perfectly reasonable for someone to talk about SAT, 03 65, Facebook, Pega, or even Angular and Containers as platforms to realize that the term platform cannot be narrowly defined. It exists only in the eye of the consumer and the person who is operating platform. This ambiguity doesn’t release the leading EA practitioner from highlighting whether a platform will be just to support one or more products. If you’re particularly mischievous you could even specify a product to make a platform to be consumed by others.
Service delivery strategy
top-level roadmaps can be expected to specify how were going to implement the transformation. Are we going to build a robust in-house capability or use third parties? Are we going to ensure long-lived sustainable systems or treat some or all of our products as disposable Kleenex?
Major value resting points
people who worked with our consulting practice no that we routinely use Value Resting Point is a public facing synonym for architecture transitions. When you are embarking on a journey it is imperative to provide your stakeholders with offramp. They will choose to execute these offramp’s for two main reasons. First, when the effort to get to the next value resting point exceeds the incremental value. This is an ROI conversation. It typically leads to a substantial of adjustment in priority.
Second one the same effort to reach one value resting point on one thread of your roadmap can be expended to reach different value resting point that is more interesting or exciting. Typically the interest and excitement will be drawn from comparative value or whether this value resting point can act as a springboard for other activity. Implementers often view these type of trade-off conversations in a binary honor off format rather than how they are viewed by the senior leaders as an investment in priority discussion.
Guide backlog in Sprint
EA practitioners who work to support portfolio and project will often engage with agile teams by guiding backlog in Sprint. It is routinely surprising to newly converted agile software development adherence that organizations who remain deeply committed to the benefits of agile software development remain deeply committed to forward planning and longer-term budgeting processes. These processes don’t exist because waterfall is preferred. They exist because it’s necessary to perform prioritization, trade-off and secure organizational resources to embark on any change program. The complete set of available change programs will exceed most organizations budget and energy allowance many times over.
Roadmap to guide product
where the EA Team received a request for architecture work to Leon to roadmap for product it’s necessary to transition the gaps, work packages, and transitions into terms that can be consumable by an agile development team. Typically this transference is done through the product owner. Where the product owner is guided and constrained by the expectation constraints inherent in the roadmap.
Roadmap to guide epic
when an organization has tightly integrated products, or tightly constrained products, or week product management the EA team will often need to associate a roadmap with epic planning. Multiple products existing in an ecosystem, sharing the pop form, sharing reference data, or consuming each other’s data exhaust will often need associated epics. This is a very difficult activity to perform and still retain the dynamic delivery that good agile software development provides. It is far too easy to fall into a trap of over specification and over design requiring omniscient EA practitioners. If you find yourself time roadmaps to epics make sure that you understand exactly why it is necessary to constrain the creativity of your software developers and system integrators. Every constraint from above has to serve overriding values and be measured against incremental value delivery that comes from unbridled creativity.
good superior architecture in the form of common concerns are an excellent set of principles will highlight constraints on value definition. If you look at worst practice agile development the sloppiness in the word value creates a large number of downstream problems. Sloppy value assessment is associated with the problems of bottom up understanding. A classic dichotomy is the distinction between tactical time to market and security, resiliency or stability. When your organization has imperatives and EA team needs to provide these value inputs to product managers and scrum teams so that they can appropriately score the backlog against measures that truly matter to the enterprise.
Constrain ‘bottom up’ product owners
many product owners do not have visibility into why their product exists or good visibility to what their products role in the ecosystem is. Roadmaps and other superior architecture can be used to constrain the freedom of a bottom up product owner either by prohibiting choice or enforcing scoring and assessment.
EA practitioners working to support project and solution delivery should expect to constrain sprints. Portfolio-oriented practitioners who are developing an ecosystem or platform should also to ask expect to work with the agile teams here.
does your architecture require something? Either in terms of your business architecture data architecture application architecture or infrastructure architecture? If it needs something to be the EA team must provide the principal, pattern, standard or rule that will constrain acceptance criteria at the end of a Sprint, or release.
Value (measures and resting points)
best practice agile software development is value-focused. Agile methods tend to be silent on how value should be determined. The quick shorthand is the product owner is expected to be able to articulate value. The question is who they are serving are they in a position to serve the enterprise or are they stuck serving the product consumers. All too often interpret his LU is sacrificed for the parochial preferences of system users.
Greenfield, Evolution, or Revolution
in TOGAF’s Phase E There Is a Step Where a Work Package Is Assessed in Terms of How It Should Be Addressed. When the Architecture Serves Agile Software Development This Assessment Defines How the Software Development Team Needs to Address a Change in an Existing Capability. Are they supposed to start from scratch (Greenfield)? Are they supposed to improve the existing systems incrementally (evolution)? Or are they expected to perform radical change in expected to eliminate the friction and hassles we have been living with (Revolutionary)?
When a product has to fit within an existing enterprise environment or support an evolving enterprise environment interfaces are key. Even when the product is emerging we may not have the freedom to allow data structure or interface to also emerge. Most common causes for this are where legislation or business plan will impact the product. In these cases the EA team has a duty to dig in and develop the minimum necessary constraints to prevent the product from requiring radical re-factoring at an inconvenient moment. Like all constraints on creativity good EA practitioners understand the importance of just enough.
EA practitioners working in an enterprise can be expected to need to step in and solve dependency and conflict that arise between products solutions and systems. Simply look at TOGAF phase G, it highlights the need for guidance and architecture change. Agile development and the scope of modern integration make this long-lived need service more important than it has ever been.
Unblock the portfolio
imagine an environment where there are numerous products moving forward creative best practice agile development teams are going to find different ways to address problems and deliver value. It’s foolish to expect that creativity will not create conflict a good EA team working in Phase G, where all agile software development happens, can be expected to work unblock the enterprises portfolio.
Cross the portfolio
product owners, and other members of a development team, are driven to incrementally deliver one product. Minimal viable product and incremental delivery lay at the core of agile’s value proposition. Trying to imagine every interaction across a complex portfolio is the failure path of top-down enterprise design. That failure path is why agile exists and why agile is preferred. It is nearly impossible to imagine a complex future. Efforts to perform this routinely devolves into farce. Yet in the real world as multiple products emerge new conflict and synergy will emerge. A good EA team with a rich understanding of the changes in priorities of their enterprise needs to monitor emerging products for synergy and conflict. When they discover intersections they need to use their insight and engagement to get the best answer on whether to and how to take advantage of the synergy, or mitigate the conflict.
just enough architecture means that every contingency every constraint every conflict was not discovered prior to release. When post-release issues arise whose implications extend past the product we have the one case where an EA Team has an emergency. Product is in the wild. End users inside and outside our organization are using it and either dealing with a defect or worse creating unanticipated risk and liability for our organization. In these events the architecture team needs to step up and do the minimum necessary to mitigate the current issue and assist in developing a longer-term resolution.
EA Capability Document Download
|Essential documents to support establishing an EA Capability|