Conexiam

TOGAF

World Class EA Series: Put TOGAF to Practical Work

Practitioners' Approach to Developing Enterprise Architecture following the TOGAF ADMTOGAF 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.

Leader's Approach to Establishing and Evolving an EA CapabilityWe saw four essential challenges needing consistent guidance:

  1. configuring your EA team, Leader’s Guide
  2. developing and using enterprise architecture for purpose, Practitioners’ guide
  3. governing creation of architecture and the implementation that are guided and constrained, Governors’ guide
  4. assembling disparate standards and reference tools, Digital Transformation: Strategy to Implementation

Conexiam addresses the imperative problems every EA Team faces

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.

Governor's Approach to Developing and Exercising an Enterpise Architecture Governance CapabilityThere 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:

Digital Transformation: Strategy to Implementation using Open Group StandardsConexiam’s partners worked together on a few projects hone our understanding. In this work we split Navigate into a universal core and specialized purposeful Navigate Atlases. We developed Predictable Enterprise Architecture™.

We tested using a TOGAF lean framework with add-on guidance with several EA Capability engagements.

Damn it works. Accelerates EA teams like a Saturn V.

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.

Conexiam’s Next Steps: Sharing More Specific Enterprise Architecture Expertise

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:

Our next step is more direct situation specific guidance. We’re going to provide it in three ways:

  1. publishing more pieces of our toolkit.
    Sometimes as snippets, like Essential Enterprise Architecture Governance, which was expanded in the Governors’ guide.
    More snippets include our Agile & EA use cases, which are briefly referenced in the CSC agile enterprise architecture case study.
    Sometimes as free versions of our hands-on training. This spring we provided a free version of our EA and Governance , Risk and Compliance (EA & GRC) course. Go ahead, take it.
  2. 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.
  3. 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.

Your Next Steps

If you are in a hurry to get useful architecture-driven change, If you want to develop your team, If you are on a budget, If you prefer DIY EA Capability development If you are pursuing personal development.

Join the conversation. Make the world a better place.

Six Agile EA Use Cases

We are always using simple framing models to clarify our thinking. These framing models is to help us to explicitly isolate conditions where the deliverables & engagement model of an EA Team changed

Isolating where an EA Team’s engagement & deliverables allows us to continually refine our EA Capability Atlas and EA Capability services. High functioning EA team’s are optimally configured to improve their fitness.

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

This use case largely exercises the TOGAF ADM’s Phase G, Implementation Governance.

Following best practice EA Governance the essential question is:

  1. 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.

A key role of developing architecture to support Solution Delivery is to identify and address these dependencies before an agile team trips over them.

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 Presenting at Open Group Ottawa 2017

Conexiam partners will be sharing our Enterprise Architecture experience work in three sessions at the Open Group Ottawa Conference. We are jointly presenting with CSC on our EA work supporting CSC’s digital transformation journey.

“Case Study: How Agile EA Delivered Value in 7 Week Sprints” Monday 9:15–10:15 AM

The case study, “How Agile EA Delivered Value in 7 Week Sprints” follows the experience of Conexiam and CSC creating an Agile Enterprise and using EA in an Agile way. The use case follows the creation of a high functioning EA team at CSC within three 7 Week Sprints. CSC’s EA team evolved from an ad hoc to fully iterative and self sufficient team within these 21 total weeks. The combination of Agile development elements along with EA governance and iteration methods, results in an agile approach to EA. Quickly identify what stakeholders needed, and map out an efficient transformative plan to accomplish stakeholder requirements. Going forward CSC is governing a multi-year initiative to create an Agile Enterprise. Using agile methods to develop EA is very effective, able to reach goals and deliver value within 7 week iterative cycles.

Murali (Kris) Venkatesh, Chief Architect at CSC and David Hornford, Senior Managing Partner of Conexiam and Lead Architect on the CSC project.

“Case Study: Transformation of a Legal Services Organization” Monday 4:45–5:30 PM

The “Transformation of a Legal Services Organization”  case study follows the experience Conexiam had with a digital architecture transformation of CSC. CSC is a legal services organization, and relies heavily on data flow, accurate repository storage and control of data accessibility. Through the case study, we will discuss the seven aspects of a digital transformation journey. The direct changes to digital architecture in this case were the development of strategic architecture, target architecture, a migration to Cloud, a selective foray into mobile, and an adoption of DevOps model. Agile delivery in EA will also be a takeaway, and how to use analytics to power digital transformation.

Present by Sriram Sabesan, Partner at Conexiam.

“Using the Open Business Data Lake Standard” Wednesday 11:45 AM – 12:30 PM

In today’s world, we are having to do Information Architectures for very complex Enterprise-Wide Ecosystems. These ecosystems have information needs that are composed of services both cloud and non-cloud, Operational Data and Business Information, structured and semi-structured, to name but a few.

Our discussion will focus on how using a standard like the Open Business Data Lake can help address the Enterprise-Wide Ecosystems Stakeholders information concerns by creating a standards-based architecture that ensures the architecture delivered is at the right level of completeness and delivers confidence to the stakeholder.

We will also discuss the future information needs of an Enterprise-Wide Ecosystems and how a standard like the Open Business Data Lake can evolve to address those needs.

Presentation by Ken Street, Partner at Conexiam

Effective Distance Education

We believe effective distance education, or self-study, requires the best available distance education and self-study techniques.

The techniques are not difficult, nor are they secret. In fact, the best distance education techniques apply basic common sense:

  • Manageable blocks of time
  • Rich collection of on-line video material and written material
  • Personal support

Manageable blocks of time

Best practices in teaching complex material are to create digestible portions appropriate to the complexity of the topic. For topics as complex as enterprise architecture and TOGAF certification, an optimal digestible portion is roughly 20 minutes in length. We structured Conexiam’s online TOGAF 9.1 Certification training into 26 blocks, each approximately 20 minutes long.

Rich collection of on-line video material and written material

We all learn best through a combination of listening, watching, reading and doing. In addition, we all have preferred learning styles for different types of material.

We have evolved our online education. Initially we partnered with Desire2Learn, the leading provider of eLearning solutions for post-secondary and corporate education, to provide a rich video/course material mix. With Desire2Learn’s Capture, we are able to blend the power of a personal lecture with slide display. Unfortunately the video quality was lower than we wanted and Desire2Learn couldn’t integrate outside their platform.

Our second evolution was to build a dedicated distance learning platform, training.conexiam.com. This portal allows us to mix multiple media, video, computer demonstration, downloadable material. We are experimenting with improving our education.

Despite our best efforts through the instructor’s explanations, the written material and the case study exercises, students have questions. To address this need, Conexiam provides three methods of additional support as follows:

  1. E-mail for straightforward TOGAF 9 & IT4IT certification questions.
  2. Optional: One-on-one tutorial with Conexiam’s instructors.
  3. Optional:Group case study boot camp

Note: The case study boot camp supports the development of a rich understanding of effective enterprise architecture. It is not a prerequisite for TOGAF certification. The boot-camp is drawn from the exercises of our EA with TOGAF & Navigate course. As an alternative we suggest that students undertake the 9 case study exercises so they can trace why the set of frameworks in the TOGAF standard are there, and why the different phases in the ADM exist.

Conexiam’s online delivery of  our TOGAF 9 training course, TOGAF, the video, and IT4IT Foundation training, IT4IT the video, were designed to provide effective distance education.

ABACUS 5.1 Update

ABACUS is an enterprise modelling tool that we use extensively at Conexiam, and we are excited with the enhancements and the improved capability of the tool.

Key changes:

  • Additional data integrations including Google Sheets, ServiceNow, and Technopedia
  • Improved speed and faster processing of data, editing features for faster modeling and more powerful analytics
  • 3D data visualizations, users can ‘fly-thru’ dynamic models of their enterprise infrastructure. Plus further visualization upgrades
  • Extended architect-to-executive collaboration features. Improving understanding of architectural intelligence
  • New icon libraries for creating executive-friendly diagrams and EA presentations
  • Extensive UI updates including improvements to reporting and publishing features.

Conexiam uses ABACUS to create architecture models that are compliant with TOGAF 9.1, and have used ABACUS’ EA models in Navigate, Conexiam’s in house methodology. Our modelling team is excited about the new changes, and have found even in the short time since release that the updates are effective and useful.

The increased depth and complexity of the models included in the 5.1 update were matched with improved model construction and viewing abilities; the models created are more detailed with better defined relationships between components, while creating and viewing the work has never been easier. Our team is especially excited about the new visualization features, as links between EA, Business Strategy and IT & IT infrastructure can be effectively presented, both between departments and at important meetings.

ABACUS 5.1 is available on-premise or as a cloud-based web-app. It is the first EA tool to be fully certified for both TOGAF 9.1 and ArchiMate 3.0 and also supports over 100 other frameworks and notations.

A webinar looking at the update can be found at: https://goo.gl/kMWyqK

We offer a free course using ABACUS to support aligning EA & GRC (Governance, Risk & Compliance). If you are looking for improving your ABACUS skills we offer specialized training.

Conexiam’s TOGAF 9.1 Certification Video Course

With Conexiam, becoming a skilled EA practitioner is now as stress-free as turning on your computer. Conexiam offers video training for TOGAF® 9.1 Certification hosted by Dave Hornford, Chair of the Open Group Architecture Forum. Top grade training for when you have the time.

We believe the ability to gain the skills and knowledge necessary to obtain TOGAF® 9.1 Certification at your pace, on your schedule without compromising on course materials and instruction is critical for effective distance education.

With Conexiam’s self-study TOGAF® 9.1 Certification course proceed at your own pace knowing you are fully supported.

The regular price of the course is $275 plus the cost of the exam vouchers

Click on this link to order your TOGAF® 9.1 Certification self-study video: www.conexiam.com/the_video