1. Twin Cities Business Architecture Forum 1/19/2016
Target’s BA Tool Journey
Background
Our needs and basic requirements for a BA-specific tool
How we classified tools in terms of abilities, value and investment
Key challenge: circular data relationships that answer BA questions. Strategy, capabilities, projects, people, tools, etc. are related in real life, but how to adapt to an off-the-shelf tool?
Ideas on how to implement a new BA mindset, process, and tool in a way that is useful and sustainable
Who are the ultimate ‘users’ of the information ?
What types of questions do they have and what key decisions are they able to make as a result of using the ‘toolset’?
Do you have an example story to share on how the info resulted in making a good decision ?  Would they have NOT been able to make a good decision w/o the toolset ?
Do you have a key business champion that is an advocate and will share the process with their peers?
Slide 4 (now 5) provides the key needs or guidelines for the tool.  Like the adoption, user centric focus.  Without adoption or usability (easy, simple) tool will not be adopted.  Item two on that slide leans into more of the information available, so I suspect the voice over is without the right information that is accurate, timely to inform decisions which goes beyond the tool.
Reference to the tool enabling effectiveness.  It might be helpful in expanding on the effectiveness or business outcomes expected as a result of having the tool.  To Pam’s point below on what key decisions can be driven from the data/information in the tool and how does the tool enable that.
Operationally, how will the data/information be maintained in the tool and conversely what does it mean for distribution of information or consuming of the information for the stakeholders.

2. Background: Business Architecture is new to Target…again
Prior to 2015, Business Architecture within Target was somewhat fragmented and not elevated to enterprise status
Formation: BA became centralized, part of Enterprise Strategy, mid-2015, team grew to 30+ team members
BA charge: manage capabilities supporting future strategies
Situation: BA left to define how it would operate
Complication: Our partner teams were also in the same boat
Goal: Define our processes and tools in a way that helped us plant a flag, but remain flexible to adapt to other partner teams’ evolving operations
Prior to 2015, there was an EA practice within IT
Formation: team formed with team members with business process consultant background
BA charge: introduce the capability vocabulary to Target, and more challenging, turn the mindset to focus both short and long term
Situation: We have related expertise but not direct BA experience, and guidance from upstairs on what are our guidelines and boundaries of operation
Complication: Every team around us was in the same situation, looking for definition
Goal:

3. Defining need: process and stakeholders we want to support by using the tool
Function
Definition
Orchestrate collaboration
Coordinate activities between stakeholders
Map Business Capability Framework (BCF) dependencies
Relationships between strategies and capabilities
Develop roadmaps
Sequence projects for shortest time, lowest $ and least people
Create and monitor projects
Create and track projects, monitor duplication
Communicate roadmap
Manage roadmaps, tailor to inform and support decisions
Stakeholders
Process
Executives
Strategy
Planning
Business Architecture
Finance
PMO
Technical 1 6
Goals and Metrics
Prioritize new and critical work 2
Communicate
Communicate enterprise priority 7 3
Translate strategy to capability language 4
Communicate Capability Enablers
As we formed the team, we decided to look for tools that could help us do our job.
We found a large variety of tools, and it became evident that the first step was defining what it was we were solving for.
We listed likely functions, and decided what we would, and would not try to solve for
We wanted a way to centralize the capability framework, and attach relationships and dependencies to enable the creation of roadmaps, and perhaps help us create and monitor specific efforts.
We decided against a tool that would help us orchestrate activities across the organization. We also decided to separate the analytical functionality from the aesthetics of communication.
We focus the user group to the strategy team. In other words, the main users would be internal to our team.
As a bonus, if we could find tools that would address the needs we decided to exclude, that would be icing on the cake, but not a primary constraint. 5
Prioritize current vs. new work

4. Defining need: The challenge we are addressing is orchestrating enterprise strategy to execution
Process: Generate epics from EKIs and organize their execution
Strategies
EKIs
Epics
Track Execution
Manage Results
People: Several pyramids and many teams need to work in concert
Strategy
TTS
EDABI
Business
Finance
Strat Exec BA
35 product groups across 104 teams
Enterprise Architects
5 major areas, 140 teams
Accountable Owners
Ops teams
Planning
What did we end up with, after we set the scope of the need? We still have a broad challenge.
Process: we need to take enterprise-level strategies, define SMART (specific, measureable, actionable, realistic and timely) projects our technical teams understand, and initiate efforts. Our solution needs to track at the portfolio or program level, not at the project level.
People: Although we would not directly orchestrate the process to execute, we need a process to interact with a significant number of resources, to enable and support the execution phase.
Communication: However, even to disseminate and initiate the execution phase, we need to consider how to interact with teams that are using a variety of tools to organize their work.
At this point, I need to differentiate the tool vs. the process it is supporting.
In other words, we need to solve the human challenge before the technical one.
We need to credibly engage with our business clients, understand their needs, and make credible recommendations.
Recommendations need to be based on analysis of people, process, technology and data, and be the product of cross-functional discussions.
We need a business champion to help drive getting us a seat at the table.
The tools are a way to be more effective at doing this work.
It helps us address the non-thinking parts faster.
It helps us uncover information too complex to hold in the mind.
It is a central repository for consistent decision.
Communication: Many methods tools available, and currently used, by different teams
Excel
SAP
JIRA
Trello
MS Project
PPT
SharePoint
VersionOne
SmartSheets
Outlook

5. Defining need: To incent adoption, we focused on simplicity and effectiveness of user experience
Manipulate data flexibly (e.g., view by strategy, capability, technology, investment, etc.)
Fast, responsive self-service any time, intuitive, easy to use
Export data, analysis, graphs
Process
Users interact depending on role and access level
Supports decision making
What happened and why?
What will happen? What if?
What are my options to improve the outcome?
Technology
No installation and no IT support
Low cost and low barriers to learn
From our collective past experience, we know there is no faster way to fail than to ask stakeholders to deal with a complicated process and tool.
We set some hard guidelines to gauge a tool’s chance of survival.
User
Once data is in the system, users can access it fast, and use it effectively to answer questions.
Process
Tool supports the decision making process. We were not sure how well a tool would address this, so we aimed to do the best we could here.
Technology
Cloud-based tool
We did not have to worry about showing return on investment. Hence, we wanted to leverage the new family of subscription based tools.
We wanted a tool we could learn the way we learn a smartphone app: interface is simple and intuitive, and minimal training is needed, if any.

6. Classifying tools: Differentiated and focused on ‘lightweight’ architecture tools
What are we calling a ‘lightweight’ tool?
Focused on business architecture (i.e., limited features)
Cloud-based tool with no installation or IT support
BA can set up and maintain with little technical background
What is a ‘heavyweight’ tool?  EA Tools
Supports and houses enterprise (IT applications and infrastructure), operations and process (e.g., detailed workflow) information ,and business architecture
Require classical large tool implementation (i.e., $$$, time, people)
Used and supported by multiple teams
Why a ‘lightweight’ and not a ‘heavyweight’ tool?
A lightweight tool is easier to understand, we can use most features
A heavyweight tool has many more features and abilities than we will need anytime soon
Lightweight
Limit features so we don’t have to train on which parts of the tool to use and which not to use.
Don’t want to deal with managing updates and the IT department. We are not an IT priority.
I believe better understanding comes when we set up and build our own foundations.
Heavyweight
Tools like Mega and Troux. We do not have the time, people and money to consider something like this. Maybe later, but not now.
Why lightweight
We want in iPhone app: simple, intuitive, built for focused purpose

7. Classifying tools: Mapped a variety of tools relative to our needs
Function
Definition
Orchestrate collaboration
Map Business Capability Framework (BCF) dependencies
Develop roadmaps
Create and monitor projects
Communicate roadmap
Stakeholder
Process
Executives
Strategy
Planning
Business Architecture
Finance
PMO
Technical 1 6
Create EKIs with Metrics and Goals
Prioritize new and critical current work 2
Communicate Metrics and Goals
Communicate enterprise priority 7 3
Translate strategy to capability language
We sampled a different categories of tools. This was a process of as much education as evaluation.
We did a cursory evaluation of tools available in the market, or within Target, and aligned to the function we could use them against.
Here is a sample of them, in areas they may have helped. 4
Communicate Capability Enablers 5
Prioritize current work vs. new work

8. Adapting reality into a tool: Mapped relationships between BA data elements
Mapped two types of relationships: associated (A) and hierarchical (H) data
Mapped how it is structured in the tool 1 2
Hierarchical relationship: one-to-one H
Association: many-to-many links possible A 1
H: L to R
BCF
Bus or Tech/Proc Org
Tech/Proc Team
Portfolio
Project
EKI
Apps
Bus Process
Capability Framework A
B/T/P Org H
T/P Team
Strategies 2 1
Hierarchy of data
Hierarchy of data
A major question was how to capture, represent and enter relationships into the tool.
There are likely better ways to do this, but this is the way we did it.
I’ll go through a more detailed example in the next couple slides. Let’s talk about the steps in general.
First Step
Build a table with the dependencies. Where there is an “A”, the two areas are related.
An “H” means the relationship is closer to hierarchical. One item is part of another.
Second Step
Draw a diagram and evaluate the relationships in terms of:
Whether the relationship can be defined
Whether the relationship can be reported but not defined
Relationship can be seen but not defined directly
Hierarchy Element
How data is entered
Data association defined
Indirect relation, many-to-many
Sub hierarchy element
Hierarchical relationship defined
Strong, close or causal relationship, or 1-to-1
Entered data and relationships into the BA tool, as best as possible

9. Adapting reality into a tool: Visual representation of the BA relationships
Visualizing the relationship map created a structure both logical enough to be built into a tool, and understandable enough to adapt to a common BA approach 1
Decision and Action Hierarchy
Organization Hierarchy
Enterprise Key Initiatives or Strategies
Business or Technical / Process Organizations
Portfolio of Projects
Teams
Individual Projects
Applications
In more detail, based on the relationship table, we identified three hierarchies.
The lines between the elements are the associations between the different data elements.
Key questions we need to use the tool for:
Enter capability gaps to plan an enterprise backlog of efforts to achieve strategy.
Record and access dependencies across capability efforts, to plan sequencing of efforts.
Central place to house many-to-many relationships, who owns what effort, what teams are working in each area, etc.
Translation Hierarchy
High Level Business Process
Business Capability Framework

10. Adapting reality into a tool: Mapping the relationships showed fit for purpose2
Data association defined
Associated or hierarchy
Relationship can be seen but not defined directly
Decision and Action Hierarchy
Organization Hierarchy
Enterprise Key Initiatives or Strategies
Strategy  Organizations
Business or Technical / Process Organizations
ResourcesOrganization Units
Strategy  Organization  [Strategy] [Elements]  Projects
Strategy  Organization Top / Child Elements
Resources  Teams  [Edit Detail]
Portfolio of Projects
Planning  Projects
Capabilities  Capability Models  [BCF lowest level]  People, Process, Technology
Teams
ResourcesTeams
Planning  Projects  Project List  Project Canvas
Planning  Portfolio
Planning  Projects  Project List  Project Canvas
Capabilities  Capability Models  [BCF lowest level]  People, Process, Technology
Individual Projects
Planning  Projects
Capabilities  Capability Models  [BCF lowest level]  Projects & Requirements VS. People, Process, Technology
Applications
ResourcesApplications
Capabilities  Capability Models  [BCF lowest level]  People, Process, Technology
Next, we determined how to get to each relationship, and noted if you could define the relationship, or report on it.
In other words, if in one location, you can define a > b, and in another that b > c, then there can be another location where you can report a > c.
Put differently, you should not be able to enter c > a, as it would negate the prior relationships entered.
Assembling this, provides a guide to the teams on where to find answers depending on the type of question.
Planning  Projects  Project List  Project Canvas
Capabilities  Capability Models  [BCF lowest level]  People, Process, Technology
Translation Hierarchy
High Level Business Process
CapabilitiesValue Streams
Capabilities  Value Streams  Add/Edit
Business Capability Framework
Capabilities  Cap Models Create

11. Recruit a tool team representing the ultimate user group
Nurturing a Business Architecture tool mindset: We are at the beginning
Recruit a tool team representing the ultimate user group
Give the team:
A vision of how BA will operate, process and tool-wise
A tool with a basic set of relationships built-in
A representative set of BA questions as part of job
A way to evaluate and document questions and needs (next slide)
A set of milestones to time-bound the effort
Leader guards the fence so team stays within scale and scope
Result: team has improved on what was given, and has reached a common view that is the key to scale to the rest of the team
Our belief is that we needed an intermediate step between getting a tool and releasing into the BA population.
Up to this point, it had been me and one or two people helping me here and there.
We needed to bring a larger set that would be a representative sample of the larger population.
The goal would be to understand and define how the tool would be configured and used, in a way that would be more palatable to the broader audience.
We just wrapped the first stage of this phase. We now have a more precise set of steps to take but need to narrow this more.

12. BA Mindset: Using evaluation of tools to illustrate the general value addressed and training needed
Approach helps us assess tools and identify areas of training needed
One approach we used was to ask the team to evaluate the tool, based on their understanding of their job.
We gave the team a set of guidelines, and recorded their feedback on usage. This allowed us to identify where we think we need to focus our training budget.