Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.
It does not take long to extend Brenda’s team: since she had such “good press” in the last few weeks, people are eager to join in. Management is a bit careful though, given that:
There appear to be several competing, informal subgroups in the organization with respect to the IS architecture, and management wants to make sure the team is balanced
There is a group of people who will benefit from a failure of Brenda’s project as they have built up a position of informal power with specific knowledge
After some careful planning, Brenda now has two sub-groups that will work semi-independently on both topics. There are bi-weekly update meetings so that everyone will get a clear picture of the progress. Also, there are no real end-to-end plans with deadlines, as the teams feel that this is not feasible. Instead, they work with a 6-8 week plan for figuring out the next iteration.
Way of working
The baseline team of four people with mostly an IT background starts with an instruction by Brenda on the way of modeling in ArchiMate. There is a bit of resistance to deal with as this is experienced staff who claim to have seen it all. Brenda realizes that most of the team members are experienced UML modelers so explaining a new language should not be too hard. She makes sure to spend some extra time in explaining the relationships as these tend to be the hardest to grasp for UML-modelers who have seen the “lines” used in ways that are vaguely similar but precisely different.
Starting with a single diagram on a whiteboard, she talks the team through the way of modeling. Most of the concepts such as functional decomposition and the use of services are understood relatively quickly by the group. As expected, there is some debate about the relations. The pragmatic remark that “this is how it was defined so, whether we like it or not, we’d better learn to work with it” settles the debate and the group quickly goes to work.
The team has decided on a simple and pragmatic approach with several workshops that all take about a half day:
Two workshops to get the “big picture”: what are they key systems that are in scope and do we have the expertise to model these ourselves or should we setup workshops with other stakeholders?
After that: 1 or 2 workshops per system, depending on complexity
Try to avoid more than two workshops for a single system: yes a system could be more complex, but ROME (Return On Modeling Effort) should be kept under consideration
The team will document everything in the baseline model package of the shared repository of the BiZZdesign Enterprise Studio and plans to create one view per system according to the structure that Brenda has laid out for them, and one total overview that only shows components, services, and nodes (i.e. the functional decomposition + platforms are left out).
The team starts digging in and quickly comes up with some first results. The CRM system and the ERP system are early targets, since they are quite well-known to the group, and moreover heavily used by many stakeholders at BriteLite. This makes it easy to fill in some of the gaps that come up during the first rounds of modeling, by verifying and reiterating with subject matter experts. In the baseline models, the architects follow the guidance from Brenda as depicted above, which leads to baseline models for BriteLite’s CRM and ERP systems as shown below.
The two teams (baseline / target) have agreed to be as open and transparent as possible. The plan is to publish a new HTML-based report on intranet just before the bi-weekly update meeting. In that way the entire organization will stay up-to-date as to what is going on, which may result in extra input and acceptance of the results.
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: