| | Spring F2F | Brenda | 4/20 - 4/22 Appeal to register. Agenda is posted on the wiki. Event hosted by Bob Guthrie as Washington University in St. Louis The format is more of an unconference. The F2F provides a collaborative framework to generate useful tools and approaches for architects. It differs from a simple presentation because it allows for deep learning and useful contributions to architecture practice. |
| | Using Capabilities Maps for common discussion and decision points. | Chuck Benson Rupert Berk | goal to enhance the governance process. Requires processes that are Complete Consistent Repeatable - Language constraint: no common frame among tech, bus, and mgmt leaders.
- Time constraint: governance structures have very limited time
- Complexity constraint: diverse and distributed structures
Chuck works to keep bus leaders engaged lest they are befogged by IT speak. Enter capability maps: - Introducing the idea of a card: presenting a capability and related services
- Cards communicate with many different groups: https://docs.google.com/presentation/d/1rkE5DQnW0SMOJLwoAGoXeFu7gjyDESSzx-4mXerPaoA/edit#slide=id.p
- Getting feedback from governance members/business leaders on the value of the card
- Chuck notes that developing and using cards entails a lot of effort, but it seems better than any other alternative
- Discussion
- Q: what struck you about capability mapping?
- A: addresses problem of discussion services and understanding them in a consistent manner. Capabilities provides an intermediate language that bridges IT and business
- Q: how did it change the conversation
- A (Rupert) facilitates discussion on outcomes and gaps
- Q: Did it give people clarity and a useful frame for collaboration and decision making
- A: Yes. It gives people an accessible basis for decision-making (rather than saying just because). Potential is huge but it is just a step forward. Work still needed to build fluency in this common language
- Q: Can you say more about scope of the business outcomes?
- A TBD. There is a wide variance and we're at early stages. Still tuning capabilities so that they are the right size, useful granularity. We will likely find different audiences needing different levels of detail.
- A (Chuck) trying to develop early definitions of capabilities and needing to evolve those according to experience. Dealing with the challenge: on the one hand, the need for iterative development with early tangible artifacts; on the other hand, the need to improve and change.
- Q: How do you map services to capabilities? How do you align specificity of capability and service? How high level are the business capabilities?
- A: There is a catalog of IT service. Goal is to ensure IT service align with business needs. Still trying to dial the right resolution of those capabilities.
- A: there is a challenging with handling present services with future/anticipated services. Settling on just the existing published services.
- Q: sources outside of U Wash?
- A: Wisconsin ones and the material Chris Eagle presented from U Mich are references. Nothing mapped completely to needs.
- Comment: useful to break up a domain into discussable units (call them capabilities). Trying to avoid treating too broad a domain.
- Comment from Laden: Chuck, I find this conversation very helpful and would like to talk you about what we are trying to do at Laurier with respect to Business Capability Mapping and our purpose of the exercise at this stage. I am not in a proper set up to chym in with my comments right now; would like to connect with you on this topic later.
- cf: Capability Maps
- Q: Do you have challenges anchoring concepts of core and enabling services?
- A: example core service might be MS outlook. Enabling might be identity management, authorization, etc.
|