Practical EA

TOGAF works when an EA Team designer approaches it as necessary scaffolding. Which I Do. Sadly, today using TOGAF requires reading past specifics. Specifics that have snuck in where a concept should be, or context-free advice that masquerades as the universal practice.

Today, it is easy to get distracted from the scaffolding hiding behind specific commentary and not see yourself.

Giving Back Conexiam’s Real World Enterprise Architecture

We leverage free Open standards, TOGAF, IT4IT, etc.
We use them to accelerate our work.

We deliberately give back. We have a long history of participating in Open Standards development. Over the past year Conexiam’s core intellectual property team pulled a consistent set of advice from our practice. Scouring our toolkit, Navigate, EA with TOGAF and Navigate training, Pilot, and Predictable EA for guidance that wasn’t dependent upon using our approach.

We donated the work to the Open Group. Following peer review the Leader’s Guide, Practitioners’ guide and Governors’ guide were published as peer reviewed papers. Today they are in the process of more substantive peer reviews and consensus necessary to become TOGAF Series Guides, representing official best-practice guidance on putting TOGAF to work.

This guidance is designed for a mainstream community commercial organizations. You need to do some mental mapping for it to work in public sector and defense.

TOGAF is an enterprise architecture framework not a cookbook

TOGAF isn’t a cookbook. It’s a framework. It should be used as a framework of essential concepts. It needs to be used by an architect.

There is not a single EA team that doesn’t use the essential universal framework. Not a team that doesn’t use the concepts. Whether they know or not. Or whether they care. Same thing as your industry value chain, or process classification framework. Your organization can use available tools to make hard configuration choices. Or not.

This point is important: everyone uses the same concepts. Not the same technique, not the same template, not the same process. Not the same configuration. Just the same concept.

Deliberately Configure Enterprise Architecture Teams

Ideally, the EA team uses TOGAF’s concept deliberately configured to their circumstances. Or, they can be oblivious and have an accidental design. I never get over the dissonance of seeing EA teams with accidental un-optimized designs. Have never seen a high-functioning team with an accidental design. Not once.

In the past, the problem we faced drafting TOGAF was the monolithic document structure. There wasn’t anyplace else to put guidance, or specific technique. Stuff just got stuffed in, here & there. It was useful. Probably.

TOGAF Journey to a Lean Framework

Today TOGAF is a fat framework. Published as a monolithic document that simultaneously tries to address enterprise architects, designers of EA Team and governors, and consumers of architecture. It is replete with random advice tucked into the middle of essential concepts.

We started our journey to converting TOGAF to a lean framework with the SOA/TOGAF practical guide. Drafting this guide was delayed as the team learned to read past the obscuring specifics and focus on the scaffolding. It was painful. The same problem with the SABSA/ TOGAF integration paper. Less painful.

I started to see the essential scaffolding more clearly. We took that vision of essential scaffolding to heart. Using it as our starting point we optimized Conexiam’s Enterprise Architecture toolkit:

TOGAF Series Guides

This is how open standards are developed. Organizations with vanguard knowledge share with their peers. We put our thinking out to be examined and improved by peers. Other Architecture Forum members have been working on similar efforts. The example TRM (Technical Reference Model), III-RM (Integrated Infrastructure Information Reference Model) and TOGAF Business scenarios techniques have been pulled out and published as separate “TOGAF Series” documents.

Frankly, I’m sorry we didn’t get further with TOGAF 9.1. While I’m proud we pulled 200 pages of chaff out of TOGAF with the TOGAF 9.1 upgrade there is a long way to go. Conexiam’s team felt it was more useful to put our energy into guidance (World Class papers, the Agile Enterprise Architecture case study with CSC), to help people read past the chaff.

Without a strong body of guidance there was no place else to put useful stuff. We now have a place to put useful stuff.

Useful stuff put together into consistent guidance, and specialization. Without a good home, we all inadvertently turn useful stuff into chaff. Specialization and specific guidance gets tucked into the standard. Specialization is not universal. Inconsistent random guidance without the backstory and context is chaff.

Hopefully, in the future there will be less chaff in the standard. Less distractions from essential concepts. Less noise that thoughtful practitioners have to read past to see themselves and see the essential concepts.

The Enterprise Architecture community has more useful guidance on how to use the TOGAF standard than at any point in time. We still have a gap. As my direct team point out, the Leader’s Guide was written for a senior leader, comfortable translating abstract management concepts into practice. Right to my face: ‘Dave, you were writing to yourself.’ Their examples:

how do you use the econometric model the Leader’s Guide speaks about?I thought it was obvious. Now I know it isn’t.

donating more specific guidance documents,
This includes a Public Sector initiative customization of the Leader’s Guide.
We are working on a version of the Practitioners’ guide specifically written for new architects.

highlighting crash & burns stories in the Enterprise Architecture Graveyard .
We all know too many EA teams are low functioning. Literally hanging on by their fingernails. If you see these practices, stop! Stop now! Do your part to professionalize enterprise architecture.

A few days ago we explored Six Agile Use Cases.That post explained a simple framing model to help us isolate where an EA Team’s engagement & deliverables change. We use this to refine our EA Capability services. All high functioning EA team’s are optimally configured around engagement & deliverables. They have absolute clarity on who they serve and who they interact with.

A foundation of our EA Capability practice is ensuring we have EA with a Purpose. (There is a quick summary of EA for purpose below)

Agile & Enterprise Architecture Interaction

To summarize the use case interaction

Use Case 2: Use Enterprise Architecture to Define Enterprise’ Agile Approach for Change
The Enterprise Architecture is used to structure how the organization performs change. Products, Sprint team structure, velocity, alignment with all change approaches are performed.

Use Case 3: Use Enterprise Architecture to Guide Backlog & Sprint Planning
From the perspective of Enterprise Architecture & TOGAF, all implementation, prototyping, pilot, project and agile sprints happen with Phase G. Best-practice EA Teams will produce roadmap replete with a solution delivery notebooks. This material needs to be described in terms fit for the backlog: Epic, User Story, Acceptance Criteria and Architecture Runway.

Use Case 4: Use Enterprise Architecture to constrain Agile Sprints
This use case is TOGAF Phase G (Implementation Governance). Following best practice EA Governance the essential question is:

Did the agile team reasonably interpret the target architecture’s documented guidance and constraint. Yes or No?
This requires the Enterprise Architecture to have provided a documented useful guidance & constraint (Gap, Work Package, Specification & Control)

Use Case 5: Use Enterprise Architecture to solve Dependency
Often dependency is where different change methods (agile & waterfall) are used and where choices within a sprint have cascading impacts.Fundamentally, if an EA Team & agile are tripping over dependency the EA Team has failed. It needs to get ahead of decision and stop chasing problems. A key role architecture to support Solution Delivery is to identify and address these dependencies before an agile team trips over them.

• Use Architecture Roadmap (Gap & Work Package) and Architecture Specification to guide prioritization of features
• Create Governance reporting for Service Delivery against value measures & motivations
Use EA Gap and Work package to define Agile backlog. Typically, in terms of Products & potentially in terms of Epics

Typically, more detailed Enterprise Architecture work will be done. Where it is not, the Strategic Architecture Work Packages will be quite large (Products and Epics)
• Use roadmap traceability (Work Package priority & dependency) and value prioritization to guide backlog grooming
Use Governance reporting to demonstrate progress towards value resting points & prioritization

Typically, more detailed Enterprise Architecture work will be done. Where it is not, the Strategic Architecture Work Packages will be quite large (Products and Epics)
• Use roadmap and concerns to guide addressing dependency between Products
• Use Architecture Specifications (Principles) to guide decision making on conflict between Products

Typically, the sweet spot for Architecture to support Portfolio
• Use Portfolio roadmap, architecture specifications and work packages to ensure teams are making the right trade off decisions
• Adjust implementation priorities based on dependency between products, platforms and services and delivery cycle of products, platforms and services
• Adjust Product and Service approach based upon refactoring opportunities to take advantage of Platforms
Use Portfolio to balance bottom-up demand with top-down demand – responding to market changes

Typically, more detailed Enterprise Architecture work will be done. Where it is not, the Portfolio Architecture Work Packages will be quite large (Epics). Portfolio work will provide a string input on prioritization drivers outside the direct line-of-sight of the Product Owner
• Provide clarity on line-of-business or product level feature prioritization
• Use architecture specifications and controls to constrain freedom of teams (Constraints should be limited to issues outside the Product)
Use the Portfolio roadmap to balance Sprint Release with Market Release

Typically, more detailed Enterprise Architecture work will be done. Where it is not, the Portfolio Architecture Work Packages will be quite large (Epics). Portfolio work will provide a string input on resolving dependency & conflict outside the direct line-of-sight of the Product Owner
• Do you have the right dependency?
• Are there Specifications to deliver the dependency mitigation bits (APIs, etc.)
• Clarify go-to market expectations and who to involve outside of product, platform or service development team
Address engagement with suppliers and partners. Specifically, constraints on delivery time they are imposing.

Architecture to support Project

Typically, limited impact. Where there is impact will come from deferred decisions that impact Go-To-Market behavior, and either Service Delivery Strategy (Agile, Waterfall, etc.) and the Product, Platform or Service release frequency based upon supplier and partner choices
• Constrain choice of service delivery suppliers and partners
• Adjust governance, reporting and escalation
Adjust release cycles and alignment with spend management cycles

Typically, limited impact. Impact will come from deferred decisions.
Architecture Work Packages will usually be Epics
• Provide line-of-business and service prioritization
• Detecting changes in line-of-business and service agility
• Detect line-of-business and service, change is escalation and decision rights.

Typically, the sweet spot for Architecture to support Project. Project Architecture provide guiding constraints to address dependency in delivery and interoperability
• Provide delivery criteria to unblock others in the portfolio (where portfolio set to align line-of-business, customer facing product or service or other transformation objectives)
• Identify the stakeholders who can unblock delivery
• Constraint team regarding interface mechanisms (ensure solutions come together with no additional work)
• Constrain team regarding service delivery (onsite, offsite platform, etc.)
• Constrain team through recommended, or required, building blocks to accelerate delivery or simplify integration

Typically, limited impact.
When it comes to balancing delivery of defect correction and new implementation, use the architecture guidance (trade-off analysis and stakeholder concerns) to prioritize backlog items accepted into a sprint.

Active guidance is provided by EA to move the implementation effort forward.

The Six Agile Use Cases explore different conditions where an EA Team must be changed.

Six Agile EA Use Cases

At Conexiam we are constantly working to develop Navigate and Predictable EA. Our development comes from multiple project team working to develop consistent our consistent approach. We are most careful when we are agreeing. Too often overlapping use of terms allows people to think they have an agreement.

Use Case 1: Use Agile Method to develop EA

In this use case the EA Capability is configured to use agile methods to develop an Enterprise Architecture.

Conexiam Predictable EA is an example of this use case. To help understand that an architecture is used to support decision making, we routinely refer to the useful work product as the “Advice Binder”. This binder is optimized to purpose and problem. It will be consumed in in several different ways.

This use case will largely impact execution of all ADM phases to develop Architecture. This use case is dependent upon the outcome of Preliminary Phase, and the structure and execution of the EA Capability.

Use Case 2: Use EA to Define Enterprise’ Agile Approach for Change

In this use case the Enterprise Architecture is used to structure how the Enterprise performs change. Products, Sprint team structure, velocity, alignment with all change approaches are performed.

The questions be addressed are what change, what development should follow which approach. In the case of agile methods, questions such as the Product, Sprint team structure, velocity are all answered.

This Use Case is largely exercising the TOGAF ADM’s Phase F, G & H based upon a Strategic or Portfolio architecture.

Use Case 3: Use EA to Guide Backlog & Sprint Planning

From the perspective of Enterprise Architecture & TOGAF, all implementation, prototyping, pilot, project and agile sprints happen with Phase G. Best-practice EA will produce an enterprise architecture replete with a solution delivery notebook, gap, control, architecture specification and work package. This material needs to be described in terms fit for the backlog: Epic, User Story and Architecture Runway.

The Enterprise architecture will contain a set of gaps, work packages to fill these gaps and limitations on the creativity of implementations teams’ freedom to perform the change. It will include traceability to drivers, goals, and priorities outside the purview of the product manager and customer.

In classic agile, the customer-driven Epics and Users stories fill the back-log. The customer provides prioritization criteria. The self-organizing agile team prioritizes work.

This use case uses the enterprise architecture to provide non-customer-based backlog and guide prioritization in sprint planning.

In this use gap Epics and User stories derived from gaps and work packages. External dependency constrains prioritization, acceptance criteria and exit criteria. Overriding priorities may be provided.

This use case mostly exercises the TOGAF ADM’s Phase G, Implementation Governance: in plain language within Phase G an implementation team is informed of the work they need to perform and external constraints on their freedom to perform the work. How the EA Team communicates is driven by the organization of the implementation team.

The critical element is aligning EA governance activity with agile change model. The momentum of the sprint team must not be impaired.

Use Case 4: Use EA to constrain Agile Sprints

Did the agile team reasonably interpret the target architecture’s documented guidance and constraint: Y/N?

If yes, their interpretation should be accepted as compliance and any issues addressed through a change to the architecture

If no, develop a recommendation to correct the situation.

This is a key point. Good architecture can have multiple implementation choices, and the agile team is not required to adhere to opinion. If the implementation choice is a reasonable interpretation, it should be judged compliant. If something was left out of the architecture specification that is not the agile team’s problem. It is the EA team’s problem, they need a change to the approved architecture.

The critical element is aligning EA governance activity with agile change model. The momentum of the sprint team must not be impaired.

The Gaps, Work Package Strategy, Controls and Architecture Specification guide and constrain sprints. They must be written and presented in terms that the agile team can consume. Controls and Architecture Specifications are typically rendered as acceptance criteria and exit criteria.

Use Case 5: Use EA to solve Dependency

In this use case the Enterprise Architecture is used to address dependency & impact across agile teams.

This use case is distinct from Use Case 4, because it changes how the EA team engages. Often where there is dependency it will be between different change methods (agile & waterfall) and where choices within a sprint can have cascading impacts.

In Use Case 4, a success measure is ensuring that momentum is not be impaired. In this use case one team’s momentum must be balanced against other agile teams, operational units and teams that use other change methods.

This use case largely exercises the TOGAF ADM’s Phase G governance & change order activity. Frankly, best practice EA Governance avoids granting exemptions to architecture cross-team dependency challenges that were not identified are the most common area of architecture exemptions.

Dependency issues are the EA team’s problem, they will need to perform work to dig the organization most effectively out of these holes Addressing these problems requires careful attention to superior architecture, Controls and architecture specifications expressed at Principles.

Use Case 6: Developing EA that enables an Agile Enterprise

In this use case the EA purpose is constrained to require acceptable Target architectures to prioritize agility.

Frankly it has nothing to do with any agile methods. Many agile organizations we have worked with don’t use agile change methods.

We draw heavily from Supply Chain & Disaster Response as high agility touch-stones. We use 5 attributes for agility (drawn from sports & military research):

ALERTNESS

ACCESSIBILITY

DECISIVENESS

SWIFTNESS

FLEXIBILITY

This use case exercises Conexiam’s Navigate Agile Enterprise Atlas. It optimizes architecture development for agility through a specialized viewpoint library, stakeholder engagement and concerns.

Bluntly, this use case is dangerous if it does not align with the true preferences of an organization’s powerful stakeholder’s.

In terms of TOGAF, this use case is most focused on the TOGAF ADM’s Phase G & Phase H value realization activity, where change must be aligned to creation and sustainment of an agile enterprise.

Conexiam offers a free GRC Training Class that includes training on how to perform EA support for Governance, Risk Management and Compliance (GRC). This training outlines how high-functioning EA teams deliver. To access the course simply create an account at https://training.conexiam.com.

This is a natural fit for a high-functioning EA Team. Best practice Enterprise Architecture has created a clear path to “improving efficiency and effectiveness” that aligns strategy, process, technology & people.

Best practice EA governance needs a small push to provide broad support for GRC.

This webinar walks through developing Enterprise Architecture aligned to purpose. Enterprise Architecture is developed for one very simple reason: to guide effective change. Effective change starts with a strategy and realizes value via appropriate solution implementation. A practitioner develops the architecture to support decision making at different stages – Strategy Development, Portfolio Development, Project Funding and Solution Delivery Governance. In doing so, we iterate through the ADM phases.

In this webinar we will walk through the alignment of purpose driven architecture with business cycle, iterating the ADM phase, exploration of EA landscape and decision making rights of the practitioner. Finally, we will talk about effective and practical governance to realize the value from the EA effort.

The Practitioners’ paper is a companion to the TOGAF framework and is intended to bring the concepts and generic constructs in the TOGAF framework to life. This paper puts forward current thinking on developing, maintaining, and using an Enterprise Architecture (EA) using the TOGAF Architecture Development Method (ADM). It describes an approach based upon the established best practice contained within TOGAF, an Open Group standard.

Conexiam uses open standards to accelerate our work. This webinar walks through an architected approach to Digital Transformation and the standards we use to accelerate the journey from strategy to implementation.

Walk through of using an architected approach to:

Formulate a Digital Transformation Strategy

Create a roadmap

Support IT delivery modernization with The Open Group IT4IT™ standard

Techniques that combine SOA/Cloud/Big Data standards and Service Design to maximize the benefits of transformation

Webinar covered how we define risk and capabilities to guide the portfolio for change and protect value realized from the transformation. Our focus is to provide guidance to the decision-makers, enable Enterprise Architects to be a trusted advisor, and to provide an implementation technology-agnostic roadmap.

Webinar based on Digital Transformation Strategy to Implementation using The Open Group Standards paper. The paper puts forward an approach for how Enterprise Architecture (EA) teams can use The Open Group standards, best practices, snapshots, and publications to deliver digital business transformation. This approach includes a proven method to accelerate delivery of value to the enterprise and frames conversations about strategy, IT delivery, governance, and digitization at all levels of the enterprise.

Primary Sidebar

Conexiam training teaches the exact tools and techniques we use when delivering enterprise architecture. Our enterprise architecture education is one of the tools used in developing a robust EA … read more ... about Training