The Open Group Press is an imprint of The Open Group for advancing knowledge of information technology by publishing works from individual authors within The Open Group membership that are relevant to advancing The Open Group mission of Boundaryless Information Flow™. The key focus of The Open Group Press is to publish high-quality monographs, as well as introductory technology books intended for the general public, and act as a complement to The Open Group Standards, Guides, and White Papers. The views and opinions expressed in this book are those of the authors, and do not necessarily reflect the consensus position of The Open Group members or staff.

The Open Group is a global consortium that enables the achievement of business objectives through technology standards. Our diverse membership of more than 800 organizations includes customers, systems and solutions suppliers, tools vendors, integrators, academics, and consultants across multiple industries.

The mission of The Open Group is to drive the creation of Boundaryless Information Flow™ achieved by:

Further information on The Open Group is available at www.opengroup.org.

The Open Group publishes a wide range of technical documentation, most of which is focused on development of standards and guides, but which also includes white papers, technical studies, certification and testing documentation, and business titles. Full details and a catalog are available at www.opengroup.org/library.

Still waiting for the alarm clock to ring, Kathleen’s mind wanders back to the meeting she had with Dick Masterson, the CIO of the company, and the chain of events that changed her life just four weeks ago. Kathleen had tried again to convince him to mandate the TOGAF^® Architecture Development Method (ADM). She strongly believed that this would help her to get some order in the chaos of all the digital initiatives. She had been trying to get his attention on this topic, but their meetings were cancelled due to “other more pressing issues”. Little did Kathleen know that the ADM mandate was just a small issue. Finally, Kathleen was able to meet with Dick late in the afternoon on Tuesday …​

Kathleen remembers she opened the meeting with a thank you to Dick for taking the time to listen to her ideas on getting the digital initiatives in order. She noticed Dick appeared tired and asked him if she could buy him a cup of coffee. Dick agreed and they walked over to the cafeteria while Kathleen anxiously kept telling herself not to let this opportunity for getting architecture standards in place slip by!

They sat down at a table next to the window.

“You seem tired,” said Kathleen. “May I ask what’s on your mind?”

Dick was not normally the type to share his problems, but apparently this time was different.

“Actually, Kathleen, I am worried. Worried about my job. Remember a year ago, when the company announced the merger of the three companies? One of the main drivers was the opportunity to transform the business. Get the company into shape for the future. I guess you know the business decided to invest in a program of digitalization, which was driven by the Business Units themselves. All kinds of teams were organized, and every Business Unit started “digital product” projects. I can tell you, most of the projects had great ideas and had great starts, but after one year, none of these intended projects have realized any value. Since we invested 30% of the budget in new hardware to support all those projects, we have reached the end of the $10 million budget. Apart from a large number of new racks in our data centers with idle running machines, we have nothing to show for it! And compounding that, there are now even more types of technology running in the data centers causing us to have to manage even greater complexity for no value. All this was justified on the premise of ‘we need to be Agile’ or ‘it’s the new industry favorite’, or ‘we must stay current’.”

Dick sighed and looked out the window. “From my perspective, in the past year we have managed to designate just about everything there is on the market as a corporate standard! Perhaps we can stop producing company technology standards and just say: ‘We have standardized on everything’. It is driving the Operations team to breaking point. I don’t think it will be long before we will have a Priority 1 (P1) incident that will disable the company for days simply because there is not enough time to both support the projects and maintain the technology environment they depend on. My only hope is that the P1 will not be a data leak.”

Looking 10 years older, Dick faced Kathleen again and continued. “I don’t need to explain to you that our company investors are starting to demand changes. Simply said, the digitalization project has failed, and our legacy systems are running on fumes. Unfortunately for me, everybody is pointing to me since it is a technology issue. Problem is, I had no control over the approvals and decisions being made. Each time I tried to get a project reviewed by my team before the business initiated it, the response was, ‘Oh, we’re Agile, so no need for you to review. If we need to adjust, we can do so because of our new way of working’. You know, our teams have been working very hard to implement Agile practices, but instead of enabling transformation, we only managed to change from a traditional project delivery to scrumming during the project execution. I’m wondering why it’s so hard for us to get beyond this change.”

Kathleen listened, realizing that her problem of not being able to get a proper architecture from all the initiatives was not even close to the size of the problems that Dick faced. She started to feel very sorry for him.

“But let’s talk about something else,” Dick said, with a weak smile. “What is it you’ve been wanting to discuss with me for the last two weeks?”

Actually, four weeks, thought Kathleen, but who’s counting? She took a deep breath and went for it.

“Well, when this Agile way of working was introduced, it also created a problem for me. I have been struggling big time to get an understanding of the architecture the company would end up with. The real issue is not that we are becoming Agile, it is the fact that our Enterprise Architecture has not followed suit. To really become an Agile workplace, our architecture needs to be incremental, with enough runway to be in sync with development. We also need to architect organizations and people in accordance with the flow of work across value streams. For the past year, we have been constantly chasing information, and when we got something it was incomplete, out-of-date, and, frankly, a lot of times conflicting. The way we see it, it’s like trying to help a team of mountaineers to reach the top of a mountain safely without knowing which peak they are climbing, and without having a joint base camp to assemble the team for the climb. The consequence is that every team member is building their own base camp at a different location and targeting a different peak to climb, which increases, not decreases, the risk of failure.”

“So, you mean to say there is no vision and no understanding of the current state?” Dick asked. “I can relate to that. I have been trying to tell my counterparts in the Business Units the same thing. We need to think about where we are now, and where we would like to end up before we start. Unfortunately, the response is always: ‘We have our vision, please do not worry about it. We do not want to be held back by past ways of working – that just slowed us down when we needed to run fast and make changes to keep up with market demand. So, please, just focus on supporting our projects where you can and leave the rest to us’.”

“Exactly,” replied Kathleen. “We get similar push back. And honestly, my team is starting to give up. They are being told that ‘old style architecture is not needed when working Agile’. I know some of my team is actively looking to find a job somewhere else. And if that happens, I think we as a company will lose a lot of tribal knowledge and that will set us back in time even more. You know, once we collect the information and put it together into a holistic view, the end architecture shows how disconnected everything is. When viewing just one project it seems very much OK, but as soon as you look across all projects, well …” Kathleen hesitated, unsure if she should be this nakedly critical. “A while back I read an article referencing work done by Mike Sutcliff and his co-authors [5] who conducted a survey among 1,350 executives to discover why Digital Transformations fail [6]. The number one reason given for failure is unspoken disagreements between top managers about goals. The authors recommend a need to ‘define and articulate not only the opportunity but also the problem it solves, and how the company will build the organization around the desired solution before investing’.”

“I get it,” replied Dick. “And I agree; we as a company are an example of such failure. But the more interesting question is: ‘How to correct it?’. We have lost a year, sunk a whole lot of money, and everybody is blaming Operations while my organization was barely able to keep up with the demand for the infrastructure and the constant need to patch up the old systems.”

“Sure, I understand,” said Kathleen. “You know, before the merger, as architects we were using an architecture methodology based on The Open Group TOGAF framework, using the elements fit for our company to develop the relevant architecture artifacts. This approach helped us to understand stakeholder concerns and develop solutions, while keeping the different parts of the company aligned. Sure, I know we couldn’t always produce quickly enough, but we did prevent chaos.”

Gaining momentum, Kathleen continued, “As you know, ArchiSurance is a member of The Open Group. So, when I started to notice the difficulty in maintaining the architecture across all the new “Agile” work popping up, I decided to use our membership benefits to interact with the architecture-related forums there and check what their response might be. Luckily, they had identified this concern as well. In fact, they have been busy defining a standard to help organizations understand the importance of architecture when shifting to Agile at scale. This is the Open Agile Architecture™ Standard (also called the O-AA™ Standard) [7]. It is perfect for us because this is what we are going through. When I started to digest their ideas, I learned a lot in hindsight about what we’ve done wrong.”

Dick was listening, but he didn’t look convinced. Kathleen carried on.

“One,” she said, holding up her hand and raising a finger to start counting the challenges. “There is no shared vision on which to base our strategy to become a digital company. All we have done is add an app to our existing products [8] and thrown the result over the wall to Operations to run and maintain them. Two,” she continued without pausing. “It became apparent that we as a company have shifted our architectural development style, but I do not believe we have been able to find the right balance between intentional and emergence.^[1] Three,” she announced quickly as Dick began to raise his eyebrows. “We failed to shift from projects to products [9]; every Business Unit chased one idea after the other based on what I consider the ‘feature of the month’, assembling and re-assembling teams into project after project. And last but not least,” Kathleen began to conclude as Dick started to shift uneasily in his seat, “on top of all that, we organized the teams along the lines of the traditional business function, which inevitably created a system aligned with traditional thinking. We should have started with understanding the business domains and the products for those domains and then organized the teams along those lines. There’s a name for doing things in this, the preferred, way. It’s called the Reverse Conway Maneuver and it results in organizing into stream-aligned teams [10]. You know,” said Kathleen as Dick opened his mouth to speak, “I have come to realize that we have adopted Agile practices in the development of these apps, but did we really look at the necessary transformation the enterprise should go through? Did we make the enterprise itself Agile? Did we miss a key point that Digital Transformation starts at the business level, not with the latest technology? Did we transform to become a digital enterprise? Did we prepare our workforce with the skills and ways of working that would help them understand how the business is changing?” Kathleen ended in a flourish with a series of rhetorical questions and finally stopped to give Dick a chance to respond to what she had exposed so far.

“This is typical.” Dick said curtly. “Whenever you experience a problem, you try to understand it with a lot of academic input. I get your point, but …​” – and he spat out each word with emphasis – “…​ I – can – not – go – with – this – type – of – theory to my business counterparts! They will dismiss it as too academic – it just won’t work here, Kathleen.”

Pulling back a little, Kathleen conceded. “OK, I always thought this type of background would be required to make people understand that our ideas were well-grounded?”

“Yes, it is,” replied Dick. “However, the time to talk about the theory is over. What if we can just start doing what you describe, instead of trying to explain it?”

“Well, there are a number of things we can do to start those changes right now,” Kathleen suggested. “And we are not alone on this. Three days ago, I met with Amy Lee, one of the Agile coaches hired by the business in an attempt to get help in collecting the architecture artifacts from the Agile teams she’s coaching. We ended up talking about the situation we are in. Amy agrees with my observations. In fact, she urged me to speak up about them, to make sure it is something the whole organization recognizes, and to build up the realization that it is not just about adopting a couple of practices; it is about transforming the enterprise. So, this means we need to get executive approval from as high up as our CEO if possible, for a sort of reset. Do you think you can convince Brad to give us the space to try and help?”

For the next two hours Dick and Kathleen worked to define a plan using a lead-by-example approach and discussed how to convince Brad to give them the approval they would need. They agreed to keep the academic part far out of sight. Kathleen made a mental note to consult with Amy again to check if she could offer some guidance. They stood up, finally, to go their separate ways.

“For the first time in a long time I feel a little more energized,” said Dick. “I’m starting to see a way out.” Kathleen nodded and smiled.

“But, you know” he quipped, “we are betting our careers on this method succeeding, right? So, hey, no pressure!”

And then he was gone.

Nearly a couple of weeks later, Kathleen sat alone in the cafeteria eating a late lunch. Despite its abrupt and slightly threatening ending, that meeting with Dick had been the motivation she’d needed to rally her team behind the idea. She could clearly see how they could use the TOGAF ADM to help turn things around. The trick, she and Dick had agreed, was to assume leadership and show results, but not force the language of the architects on the rest of the organization. The team had worked hard to build a vision to digitalize the company and define the corresponding organizational setup to deliver this vision. Still, she felt she was missing something.

Suddenly Kathleen was woken out of her train of thoughts by somebody saying, “You seem far away. A penny for your thoughts?”

Kathleen looked up. It was Amy, standing next to her with a tray.

“Mind if I join you?” she asked with a smile and, without waiting for an answer, she slid into a chair on the opposite side of the table. “So, what’s keeping you from enjoying your food like people normally do?”

“Nothing,” Kathleen said, letting out a sigh. “I’m just considering the fact that I have promised to help somebody, but I’m getting stuck and probably won’t be able to help. I have this nagging feeling I’m missing something.”

“Ah, I understand,” said Amy. “I guess the conversation with Dick was positive, but you feel the task is too much to handle?”

Kathleen looked up. How could Amy know of her conversation with Dick? But before she could ask, Amy continued. “Have you considered you are falling into the same trap as always?”

“No, we are not!” replied Kathleen, somewhat annoyed. “We studied all the material available and are doing everything we need to do. We have defined the new vision and strategy for the business model and the products we need. We’ve started to align the organizational setup required to build and maintain the solution. We are going to create the necessary designs. All of this has been achieved in less than two weeks. I am very proud of my team and I think we have done a –"

“Exactly!” said Amy, with some concern in her eyes. “I rest my case.”

Kathleen halted her monologue and looked bewildered at Amy. “I … I … Well, this is something,” she stumbled. “Last time we spoke you urged me to speak out and I did, so where is the problem?”

“Well,” said Amy calmly, “you did speak out, but within your own bubble, or silo. If I am right, outside the Architects team and Dick, there is nobody else involved in the grand design you are talking about. In fact, as I see it, you have locked yourself and your team into a room for the past ten days and came up with an architecture. And I can only guess you are going to continue to design the details so you can plan the transformation of ArchiSurance for the next year or so, which you are planning to present at the next town hall meeting?”

Kathleen sat back and shook her head in disbelief. How could Amy know this was her plan? “Well, yes. Exactly! It’s what will be needed to convince the leadership to transform: a well thought through plan, with a clear goal.”

“Sure,” Amy replied, with a slight shrug. “That is how it always has been done. Was this not also the way the current ArchiSurance digitalization plan was agreed upon?”

Kathleen stopped talking and started to laugh. “So, you mean you think I am losing my mind?”

“No, no, no,” said Amy, with alarm. “That is not what I meant.”

“I know,” Kathleen replied with a big smile. “But to quote Albert Einstein, the definition of insanity is doing the same thing over and over again and expecting different results.”

Amy started to laugh as well. “Not exactly what I meant, but it does apply. The issue is that it is best to prevent BDUF.”

“BDUF?” Kathleen asked.

“Yes, Big Design Up-Front: trying to iron out everything to the detail, spending months on it, and in the end being overtaken by reality once implementation is starting. You should not drive a transformation like this with a BDUF. You should try to find the right balance in providing guardrails for the transformation versus room for concepts like emerging design.”

With the tension broken, Kathleen shifted gear. “So, thinking it through, I believe we are doing good things but, as I said, I believe there is something missing. Any idea what that could be?”

Amy considered the question for a couple of moments before replying. “As you know, what drives the transformation of ArchiSurance is the increasing demand to improve the customer experience; being able to adapt to changing market conditions and improving customer intimacy. The best way to achieve this is to become both more digital and more Agile. So, we need to establish both a Digital and an Agile Transformation. The current approach and the approach you are defining now contain a lot of good things, but they are not addressing all seven levers of such a Digital Transformation [11]. What is needed is to frame the problem statement and the necessary operational steps to realize the strategy. Transforming the delivery of digital products is in the middle; realizing the agility, efficiency, and decision support goal.” Amy paused to check Kathleen was with her so far. Kathleen nodded and Amy continued with her assessment.

“The problem with the current approach is that the transformation is mostly happening at the individual and team level. Teams are adopting Agile practices to work differently and, I can tell you, I am spending a lot of hours consulting the different teams on this topic and they are changing. But, it does not address Agile at the enterprise level. There is no Lean or Agile leadership that drives this transformation. So, the problem with your current plan is that it is mostly addressing the solution space – defining the business model and the platform. However, it contains too much inside-out thinking and doesn’t address the actual problem space.”

“OK,” said Kathleen slowly. “So, how do we change this?”

“First, I would involve the business in defining the strategy and the plan to achieve this. Given that ArchiSurance intends to define new products around customer intimacy, you could apply design thinking and journey mapping to define the problem and scope the solution. You can also start to develop a shared purpose and accountability across all levels of the organization by involving those that need to execute the plan in the planning process; for example, using catchball. And as we discussed earlier, I would certainly urge you to stay away from the normal architecture practices and allow the architecture to be built iteratively – so no BDUF, just enough to provide guardrails for the teams.”

Amy and Kathleen decided one of the main elements was to correct some of the organizational setup mistakes that had resulted in the plethora of independent project teams, structured according to the existing organization.

“We need to make sure,” said Amy, “that we organize ourselves for the outcome we want to achieve, because organizations typically design the systems that mirror their communication structure.^[2] So, if the current system is not what we want, we should start with looking at the organization and applying the Reverse Conway Maneuver.”

They identified the initial concepts of the end-to-end value streams from a customer perspective, and the products that needed to be delivered, which could help the organization shift from thinking in delivery of projects to delivering products.

By the end of the afternoon, Kathleen had a clear picture of how she would be able to define the plan to achieve ArchiSurance’s intent to become more digitalized.

“This is great,” said Kathleen, as they prepared to leave. “You’ve really helped me to see how this can be done, but I do need to get back to Dick to ask him to talk to Brad to get everybody aligned in helping out.”

“Oh, don’t worry about Brad. I don’t think that’s necessary. Just take the lead and show the way,” Amy replied, walking away and leaving Kathleen puzzled. However, over the next few weeks, everybody started to align and contribute without the need for Kathleen to force participation.

Kathleen and her team of architects had set out on the task and conducted interviews and workshop sessions with business representatives, using design thinking to set the goal for the Digital Customer Intimacy theme. This solidified the initial concepts and adjusted them based on collaborative learning. In the background, her team had dutifully used the information to build the necessary architecture artifacts and, as she kept reminding them, with just enough architecture to help the organization to progress: “We need to make the architecture emerge out of our collaboration.”

It was a new experience. Normally, she had to beg for time from the business stakeholders to involve them in workshops and in the design reviews, but this time it was as if they all wanted to be involved.

All, that is, except for Hans Pickle, who kept insisting that his team, which was working on the replacement of the Prolongation Application (or as everybody else called it, the “Big Ludicrous Old System”, or the “B.L.O.S.”, application), was to be left alone and outside of the change. His team had now been working on this replacement for 14 months and his argument was that the investment in it was too big to change direction and they would need only another two to three months to be able to release their work. And, according to Hans, “My team is the most experienced Agile team in this company, they have been scrumming now for over a year, so you do not need to touch this area; we are as Agile as it can get.”

Kathleen recognized that Prolongation was one of the capabilities of the value stream to manage the lifecycle of a sold contract, and she would have preferred to make it part of the Manage Digital Customer value stream. Numerous attempts at trying to change Hans Pickle’s mind, however, had failed to work and Kathleen decided to compartmentalize the Prolongation area and work around it, making the B.L.O.S. its own value stream. She felt, personally, that the focus on replacing the B.L.O.S. was not correct. In all her conversations with the business about any changes required, the B.L.O.S. system was never mentioned. Sure, there were issues, but they had to do with providing information to help the conversation with the customer, and not the functionality of the core system itself.

All in all, they had spent only four weeks building the first iteration of the Architecture Vision and the Business Architecture (see Bonus Section A and Bonus Section B). Together, these represented the architectural intent for ArchiSurance in its quest to become more digitalized, and showed the corresponding organization that would be required. They had been able to use the new way of doing architecture.

Now, feeling confident that the architecture built so far would be compelling, it was time to lift the curtain and get the whole organization behind the initiative.

The alarm clock finally begins to buzz frantically, snapping Kathleen out of her reverie about the origins and impetus for today’s exciting presentation. Next to her, Sven, her husband, groans and mumbles in complaint.

“Why always so early, Kathleen? When will you get a normal job with a normal schedule?”

Kathleen kisses him and pulls the sheet over his head to help block out the lights as she turns them on. She’s still thinking through her presentation as she brushes her teeth. And after running the presentation over in her head several more times, Kathleen finally grabs a piece of fruit from the kitchen and heads out the door. It would not hurt to be at work early today.

Kathleen arrives and sees that several members of her team, Tony, Terri, Rakesh, Greg, Philip, and Chris, are in early as well. She greets them with a wide smile, and they all grin back knowing that this will be a historic day for ArchiSurance, a day that will change the company dynamics forever. The team is particularly excited about the seven core principles they have come up with around the theme of “Working Together to Drive Our Digital Transformation”. These principles will be a key message in the presentation to leadership:

With only about 30 minutes until showtime, Kathleen makes her way to the auditorium with Terri and Chris, two of her closest team members. As she enters the building several people greet her and wish her well for the presentation. She feels clear support from over half of the company’s leadership, but there are still a number of leaders that are cynical about change or who are concerned that they will lose the empires they have built. Kathleen knows she needs to convince those wary of the value of the proposed change to the organization, and she needs to show the empire builders the leadership opportunities available to them as the company shifts away from a vertical, silo way of working toward the creation of autonomous and empowered cross-functional teams that work together across value streams.

The room is filling up with the company’s leadership, including managers, directors, vice-presidents, fellows, and Six Sigma master experts from all of the functional groups and product lines. Brad Nelson, the company CEO makes his way to the front, shaking hands and greeting people along the way. Kathleen catches up to him and they walk side-by-side to the front of the room. Before she knows it, they are on stage and Brad is introducing her.

“Please welcome Chief Architect, Dr. Kathleen Stone. She is the inspiration behind our Business Architecture and the new organizational design.”

The room fills with applause.

Kathleen thanks Brad and begins her presentation with a vision for the future.

She begins, “I’d like to start at the end.”

“That is,” she continues, “I’d like to help you imagine what things might look like if we already worked in a digital enterprise. So, I’m going to ask you to sit back, close your eyes, take a deep breath, exhale fully, and just imagine.”

Kathleen waits for the room to settle.

“Now, imagine that we work for a company that has broken down all functional silos. In this company, we work together across value streams and are accountable for achieving common goals and objectives. Each team has a shared funding model. Business value is delivered on all technology investment decisions. Customers are happy with their experience. This company has mastered the use of Agile practices from strategy all the way through execution and operations. In this company, the IT department is no longer taking orders from the business. IT has a seat at the table with the business and is seen as a strategic partner. There is no “business” or “IT”; it is one and the same. Strategy development is not just a once-a-year occurrence. Instead, business and IT work hand-in-hand continuously to make incremental improvements, and we control the products and the supporting backbone we need to deliver value digitally. The result is a team of teams that is capable of delivering our products on time with the quality and innovation that delights our customers.”

She pauses for a moment. “Now open your eyes.” She smiles as her audience opens their eyes. They blink and look around at each other.

“Congratulations! From here on out, you are part of our journey to make that imagined vision of our digital enterprise a reality.”

Kathleen goes on to talk about ArchiSurance’s earlier accomplishment of merging three companies into one. The streamlining of processes and the rationalization of systems that has been done so far, she points out, has left ArchiSurance in a good position to optimize the organizational structure with cross-functional teams.

“We have made great strides in Agile development through our DevOps initiative, but did we really go beyond the implementation of Agile ceremonies? Is it really Dev and Ops? I think if we are honest with ourselves, we did not change much more than the introduction of scrumming as a way to develop software and we kept everything else the same. So now it is time to get our core operational value streams in order with teams that work together.”

Kathleen then shares the news that her Enterprise Architecture team has been working with business representatives, strategy leaders, and Portfolio Managers to develop key value streams that will be rolled out over the coming year. Each value stream will have its own funding and will have a cross-functional team that will sustain it from strategy through execution to operations. The cross-functional teams will be supported by a newly formed Office of Digital Products.

Kathleen flashes up Figure 2, a Business Architecture model of a key value stream,^[3] and talks about the capability assessment that was performed for each stage to determine opportunities that can be prioritized and worked by cross-functional stream-aligned teams. Each capability assessment had taken two to three weeks with dedicated resources from Business, Strategy, Architecture, and Portfolio Management. Additional resources had been brought in as needed once the gaps and opportunities were identified and prioritized.

“We had,” adds Kathleen, “already identified some of the gaps due to a high-level assessment that was completed at the end of last year. They included our ability to execute digital customer management and data-driven insurance product offerings.”

Kathleen brought up the next slide, Figure 3.

“Here are the results of the environmental scan we did with our stakeholders. First, we used a SWOT analysis to gather individual stakeholder assessments on our strengths, weaknesses, opportunities, and threats using a questionnaire for them to complete. Then we brought the stakeholders together to synthesize all of the information collected. As you can see from the slide (Figure 3), we also completed a PESTEL analysis^[4] to get a sense of all of the external factors (political, economic, sociocultural, technological, environmental, and legal) influencing our environment. The results of this environmental scan informed our Business Architecture. We believe this kind of input from our key stakeholders, including customer representation, will drive wise investments in our digital products” [14].

Kathleen moves to the next slide, Figure 4. “This is an organization map [15]. It will help us with the initiative we are embarking on; to improve our understanding of the organization, strategic planning, organization context for deployment, communication, and collaboration.”

“I combined this organization map with guidance from a recent book called Team Topologies: Organizing Business and Technology Teams for Fast Flow by Matthew Skelton and Manuel Pais [10], which introduces the concept of stream-aligned teams to provide an even more Agile way to structure ourselves to achieve our objectives.”

Kathleen had designed the team structure in such a way that the teams are as autonomous and self-organizing as possible. The teams can each make decisions; the aim being to minimize dependency on other teams. This level of autonomy and self-organization may not always be possible and over time she knows the organization might have to shift the focus of teams, but the aim is to create flow and drive value.

She goes on to say, “One immediate gain expected from this new way of working in cross-functional teams will come from productivity driven by aligned roles, processes, information, and tools as well as new capabilities identified from technology and automation opportunities. Many of the essential capabilities are noted on this chart and are linked to the responsible group. The stream-aligned teams will be optimized for the flow of work and the Platform team (not shown) will allow the stream-aligned teams to focus on day-to-day activities while they provide support. Note the relationship of each team for building the digital value delivery we have identified. Common goals will be agreed upon across each value stream, which will shift the focus to identifying technology investment priorities as a team. The result will be higher customer retention, increased market share, revenue increases, and productivity improvements.”

As she concludes her presentation with a high-level roadmap of the value stream implementations that will support the Digital Customer Intimacy strategic theme, Kathleen remembers that in meetings like this, where she is communicating to upper management and the lines of business, she should close using their language and summarize the business benefits.

“Now,” says Kathleen, squaring her shoulders and turning to make eye contact with the most influential leader in the room, “I want to bring it back to what this initiative makes possible for our business going forward. When we re-orient ourselves to optimize the value streams that most impact our customers, you will see faster delivery times from Idea to product, better ability to return customer feedback and requirements into the product delivery lifecycle, increasing product satisfaction ratings from customers over time, all of which should strengthen and grow our competitive advantage in the market. So, what questions can I answer for you?”

The presentation is well received. After a few questions, Brad steps back onto the stage of the auditorium to thank Kathleen. Kathleen expected Brad to form a working group to help in validating what would be adopted from this plan but, to her surprise, Brad announces he has been talking to all the business leaders on the plan and they are fully behind this new approach and are looking forward to the first results over the coming months. In short, this means the approval has been given to begin work immediately on the first value stream, which is more than she had expected. Brad closes the town hall meeting, and they walk off the stage together.

“Good job,” says Brad, with a smile. “Thanks for getting the organization behind this plan in such a collaborative manner. That’s what I expect from the Enterprise Architects; leading by example, not designing from a distance. Keep it up and keep me posted!”

Kathleen watches as Brad walks away. She is really surprised. She knew he would have been informed of the plan, given he put it on the town hall meeting agenda, but she had never presented it in person to him and still he endorsed it in full today. As Brad makes his way through the crowd in the auditorium, Kathleen notices he signals Amy. By the time they leave the auditorium they are in deep conversation.

On the way back to her desk, Kathleen receives a text from Dick, the CIO, to ask her to stop by his office. She makes the detour and arrives at his door with a little apprehension. Was he happy with her presentation and the results?

“Fantastic job, Kathleen. It’s really great to see we have such a bright future, and thanks for pulling this all together. I assume you will make sure this transformation gets top priority. Just make sure it has the right attention. Any help you need, don’t hesitate to ask.”

Still beaming with excitement from the presentation, Dick’s comments to Kathleen affirm her feelings that this work is some of the most important going on in the company.

“I look forward, then,” he says, “to seeing your budget proposal and monthly Board updates.”

Kathleen nods and turns away to continue to her office, but by the time she arrives her thoughts are racing. What did Dick mean, the budget proposal and the monthly reports? She has approval for the transformation as a result of the presentation. Surely, it’s clear to the organization which changes need to be made and which product development needs to get started?

Completely puzzled, Kathleen sits down behind her desk. What was Dick referring to and what is she missing? At that moment, Carl Highfield, one of her Solution Architects walks in.

“I was really impressed with your presentation, Kathleen. I’m thrilled to be part of this journey.”

Kathleen nods but doesn’t reply.

“You seem worried,” Carl says. “I thought it all went very well?”

Kathleen shares with Carl the exchange she just had with Dick, especially the part about needing to obtain budget approval. Carl’s face lights up. “I can help you with that!”

For the next half an hour, Carl explains all the documents that need to be created, exactly where they would need to be stored on the company’s document collaboration system, and the list of people that would need to be informed of the existence of the documents so they could process them and create the necessary dashboards.

“How long will this take?” Kathleen asks.

“Oh, normally about six weeks to get through it all. But if you’re very quick, you might be ready in four weeks.”

Kathleen gasps. “Four weeks? This can’t be true. I need an answer next week!”

Determined to beat the system, Kathleen starts looking up templates for all the documents she needs in order to get the approval. Three hours later, she is completely frustrated with all the duplication of the required information and the complete lack of re-use. Even the work she and her team did with architecting the future is to be repeated in another format. She decides to go home and pick up the task again tomorrow.

Arriving home, she is greeted by her husband, Sven, who opens a bottle of wine to celebrate.

“How did your big presentation go? And when are they going to promote you?” Sven laughs. Kathleen shares the success of the presentation and of getting the approval for the whole initiative, but also her frustration at the troubles that met her the minute she got started on it.

The next morning, before leaving for his office, Sven catches her and says, “You know, I recall that one of my customers had a similar problem with an overly manual and laborious process of getting a budget. They managed to improve this by using something they called “Strategy to Portfolio”, which I believe is part of the IT4IT™ architecture. This isn’t my area so I don’t know more than that, but perhaps this IT4IT thing can help you as well.”

Back in the office, Kathleen starts researching “this IT4IT thing” and finds out that Sven was referring to the IT4IT Reference Architecture [16], a standard from The Open Group that helps to manage digital products. Through her investigation, she learns that the IT4IT Standard is value stream-based from the outset, which resonates well with her. She is looking at Version 2.1 and notes that a Snapshot of Version 3.0 [17] is available, so it is still in development and will evolve. She is excited to see that concepts like “digital product” will be introduced and the value stream concept will be further enhanced. Luckily, it is a reference architecture, which means she can choose the elements she needs. In this case, Kathleen needs the functional components and their related data objects, including the digital product concept, grouped into value streams to help her solve the issue at hand. One of the IT4IT value streams is the Strategy to Portfolio value stream for planning, which includes the Enterprise Architecture function. As she digs deeper, she learns that the IT4IT Reference Architecture aligns really nicely with the methodologies of the TOGAF Standard, which ArchiSurance is already using in its architecture practice.

“Very impressive,” she looks up and says out loud to herself. “This could definitely help us.”

She continues to read and is happy to see that with the selected concepts from the IT4IT Reference Architecture she is able to define the data that needs to be collected by various digital technology management tools. A good example is her own Enterprise Architecture tool, where her team is already capturing business drivers, goals, policies, and architecture definitions as suggested by the TOGAF Standard. There are both Policy and Enterprise Architecture functional components outlined in the IT4IT Strategy to Portfolio value stream, along with the data objects to be managed within each.

Kathleen wonders if this will map as nicely for some of the other tools they use every day across the product lifecycle. She decides to check this out with Sarah Condor, Head of PMO, and gives her a call.

“Hi Sarah, this is Kathleen. I was wondering if you could help me with something. We have been working hard on the definition of our ArchiSurance value streams so we can start on the digitalization journey I shared during my presentation yesterday.”

“You did a great job painting a vision for what our company could be!” says Sarah. “I’m so excited! How can I help?”

“Well, when I went to get the budget released for all of this, I found I need to do a lot of work manually. I was wondering what your team does with the information stored in the various documents you’re requesting?”

“Oh, once approved, most of the information is stored in our Portfolio Management tool, which we use to track each of our products and initiatives.”

“OK. So, is there one central place to store the information?”

“Well, yes and no,” says Sarah. “A lot of the time, we simply point to the documents stored on our document collaboration site or to the dashboards we have created using those documents. But yes, a lot of information is stored centrally once approved. In fact, one of my PMO resources has a full-time job ensuring our Portfolio Management tool has the right information.”

“Why is this done after approval?” asks Kathleen, puzzled. “And why do we store information that is not necessary at all?”

“Oh, very simple,” says Sarah, with some resignation. “We have always done it this way! And, of course, each team – like Finance and Human Resources – needs the information in their very own format.”

Kathleen gets excited as this is a problem with which she is very familiar.

“One more question, Sarah: This tool you are using, could that be used outside your team? And could we configure it to capture other data and integrate with it if we needed to?”

Sarah shrugs. “Of course, that is possible, but so far, nobody has wanted to do this, and I’m not able to find the time to drive this kind of change.”

As Chief Architect, Kathleen makes the decision to incorporate the digitization of this process for creating and approving an Idea into the vision for Digital Customer Intimacy. After all, she thinks, testing herself on her justification for this decision, getting our internal operational processes in order will ultimately help the customer. We can’t continue with this chaos, she argues to herself, it just keeps stealing away valuable time needed to work on all of the technology enhancements we are being asked to deploy for the business. This IT4IT Standard, she concludes, will help to introduce value stream thinking across the entire digital technology department. Initially, it will be especially useful for improving information flow across technology functions, but eventually, it will also be useful across the business.

Having finally convinced herself, Kathleen is confident with her decision to use a combination of The Open Group portfolio of open digital standards for the ArchiSurance Digital Transformation. Her Enterprise Architecture team has already been using the TOGAF and ArchiMate^® Standards for a few years.

Kathleen knew that each standard would help in a unique way:

Apart from these standards, The Open Group has many more standards that can also provide guidance; such as:

She also begins to think about the cross-functional teams being formed. The development teams will be able to take advantage of the IT4IT value streams as the driving force to transform the way of working, for as long as they are needed. The stream-aligned teams that develop the insurance products will design them using the ArchiMate language and store those designs in the Architecture Repository as defined by the TOGAF Standard. They will also leverage the four IT4IT value streams to manage the digital product lifecycle of those insurance products. Finally, the staff can leverage the DPBoK Standard content and training to become Digital Practitioners and use the DPBoK emergence model to spin up small, fast pilots, which – if they prove successful – can be moved into the mainstream of the enduring enterprise. The DPBoK Standard also provides a rich set of resources to help us better solve hard problems of coordination, governance, and architecture in a way that supports our product teams, avoiding needless bureaucracy. Finally, the O-AA Standard helps the Architecture team to understand how to become Agile themselves and successfully collaborate with Agile teams so they are not a blocker but an enabler of stream-aligned teams. This Digital Transformation is beginning to shape up nicely thanks to the accelerators being provided by The Open Group standards.

Kathleen arrives back in her office after meeting with her Enterprise Architecture team. She focuses on her plan to include the IT4IT Reference Architecture to structure the flow of work through the product lifecycle. This could be the way to keep track of all the artifacts and deliverables for this initiative, from strategy through execution and operations. A plan forms and she emails Dick to schedule a meeting.

As she studies Figure 6, Kathleen realizes that the results of the Architecture Vision (Phase A of the TOGAF ADM activities) can be stored in the Enterprise Architecture Management tool, covering two of the IT4IT Reference Architecture components: Enterprise Architecture and Policy.

This plan, she learns, can be expanded using the functionality available in Sarah’s Portfolio Management tool, which has a wider set of capabilities than just managing a list of Portfolio Backlog Items. It can be used to manage an Idea (the Portfolio Backlog Item) from initiation to decision-making, allowing the storage of necessary information as soon as it is created. It can also be used to link the Enterprise Architecture Management tool, and other systems, such as the Finance system, to prevent the retyping of information, and to start streamlining the whole process.

An approved Idea will automatically become a definition of a Proposal (Scope Agreement) and a corresponding service item can be created using the captured information. This means the Portfolio Management tool will cover the remaining IT4IT Reference Architecture functional components and data objects, and provide the linking of information:

With this plan, the ArchiSurance Digital Product Portfolio will have complete coverage of the IT4IT Strategy to Portfolio value stream automatically linking the TOGAF ADM Architecture Vision results to the decision-making of an Idea.

However, one thing keeps nagging her. Changing and integrating the tooling used in the process will optimize the current way of working, but will not change how ArchiSurance plans its investments. The budget is still allocated to projects just once a year, so even if a new Idea can be better processed, it is highly likely it will still need to wait till the next budget round. She knows her Idea will get funding, but in between budget cycles it is impossible to change the course of the organization unless you are backed by the CEO. Remembering she had read something in her investigation on the DPBoK Standard, she decides to get some inspiration from that body of knowledge. In Section 6.3.2 [1] she finds the root cause of her concerns. The “budget contracts” become a top-down performance commitment forced onto the teams. If ArchiSurance wants to become Agile as an organization, it requires a rethinking of the way investments are managed. Luckily, there are a number of principles and guidances provided which will have to be implemented as part of the way of working. Kathleen is happy to see that the adjustments in tooling based on the IT4IT Standard are actually going to support ArchiSurance in this adjustment.

“So, how about we apply the same approach we took with the business?” asked Kathleen hypothetically, as they reviewed the plan in Dick’s office. “What if we could implement a value stream that supports us in making better and faster investment decisions? What if we could free up resources to do more valuable activities than retyping information from documents into systems?”

Dick is very interested and once Kathleen has explained her Idea, he gives her the green light to go ahead and implement it, using a discretionary budget so she will not be delayed or blocked by the existing approval process. He also commits in helping Kathleen to establish the new way of working, starting with the executive level. It will not change overnight, but he is convinced it will work once everybody starts to see the benefits.

Excited about this new way of tracking the company’s products and services throughout the lifecycle in one place, she calls her Enterprise Architecture team together to let them know the good news.

“Now, not only will there be a consistent way to store architecture artifacts, but we may also have the capability to continually drive Ideas through the decision-making process more easily.”

Kathleen goes on to tell the team that she plans to focus her efforts on getting the Strategy to Portfolio value stream pieced together.

Kathleen forms a small team which, over the course of the next three weeks, sets out to build a Minimum Viable Product (MVP) leveraging the existing systems. The team started by looking at the Strategy to Portfolio value stream in the IT4IT Reference Architecture and were very quickly able to sketch out a simple diagram of the proposed system integrations for the MVP.

First, the team researches Section 6.3.2 “Investment and Portfolio” in the DPBoK Standard [1] to gather information requirements. Then, the team updates the configuration of the Portfolio Management tool to capture the additional needed information, create the necessary dashboards to support the decision-making, and capture the decision to budget within the tool. The team agrees with the Finance and Human Resources team on how to export the information, which they agree is “good enough”. They then implement a first integration with the Enterprise Architecture Management tool. Sarah and her team chip in and guide the Implementation Team during this work. They even manage to identify ways to further reduce the amount of information that needs to be captured while still allowing proper decision-making.

By the end of the third week, there is agreement on the simplified approach, reducing the time it takes to bring an Idea to decision from six weeks down to just a couple of days. Using her own initiative as a pilot to validate it, she does a demo for the leadership team and in the weeks following, one by one, all of their Ideas are acted upon using the new approach.

The next step, thinks Kathleen, is to change from budget reviews with monthly updates to a Quarterly Business Review (QBR), so we can make decisions based on value and not only on cost. The implementation we have completed based on the Strategy to Portfolio value stream is ready to make the shift. Now it’s time to help other people make the shift.

This will be her topic to discuss with Dick when she sees him next.

Since the merger, a lot of different work has been spun up and delivered, with only small successes. However, for this Digital Customer Intimacy strategic theme, there are several initiatives and the teams are bigger than normal. Four weeks after starting up the teams, Kathleen starts to see them drifting apart. She decides to pull in Carl Highfield, the Cloud Domain Architect and the primary Solution Architect who worked on the merger activities, to lead the Digital Customer Intimacy Solution Architecture. However, she does not want another layer of bureaucracy, so she asks Carl to come up with a structure in which the stream-aligned teams remain autonomous and self-organizing, which should also help prevent unnecessary meetings and review boards.

Within one week, Carl identifies that all the different teams have been working at full steam on their first releases. He quickly finds that they are not aligned on the way they are representing the Information Systems Architectures, leading to misunderstandings between teams. Carl decides to make it a collaborative effort and teams up with Chris Keller and Jamar Johnson, the Solution Architects embedded in the two stream-aligned teams. Together, they decide to harmonize the Solution Architectures based on what has been developed already. They set up a series of alignment meetings to be able to iteratively develop the architecture and keep each other informed on the progress they are making through the cycles.

In fact, both architects had already developed a lot of material in earlier iterations of the infrastructure architecture because they had already been thinking about the solution in their roles as participants in the stakeholder meetings with the business, and they have been supporting the Development teams since the merger. On top of this, Chris already has a reference architecture for Big Data that he developed last year. He has been able to use several building blocks from that to speed up the Solution Architecture effort.

Kathleen is pleased to see that not long afterwards, Carl calls a meeting to show the first iteration of the Solution Architecture in which Chris shows the Information Systems Architecture and Jamar shows the Technology Architecture. Again, she finds the ADM cycle helpful in building the architecture iteratively, but it’s not necessary to force the vocabulary of the ADM. In this way, it is possible to let a coherent product architecture emerge over time using multiple Agile teams. Chris, Jamar, and Carl are using this approach to lead the other teams by example, and also using the ArchiMate language to document the architecture (see Bonus Section C and Bonus Section D).

At the end of the meeting, Jamar and Chris ask their colleagues if there are any questions on what they presented.

“I have a question Chris,” says Terri. “I was wondering if you could elaborate a bit more on the building blocks you developed for Big Data. I know they really helped us go faster and I’m wondering if there are any other building blocks we can get in place to make our architecture work more Agile.”

“As I’m sure you all remember from our TOGAF Certification classes,” says Chris, “building blocks are reusable components of a capability that can be combined with other building blocks to deliver architectures and solutions. So, the building blocks that the Big Data team built began last year when we developed a Data catalog with details on our key data sources. Next, we deployed a standard technology set for our Big Data environment. Once we had enough of the infrastructure in place, we were able to develop a self-service reporting module and then we built interfaces to some of the core data sources. It just so happens that we already have interfaces in place for lots of the customer data required for this initiative. There are only a couple more needed and we have building blocks such as the Data catalog, the standard technology set, and interfaces that can be re-used to make them go very quickly.”

“Thanks Chris. I think there are lots of areas where we can use building blocks to help us build Architecture Runways, which will allow us to deploy solutions faster. Definitely something to keep in mind.”

After the others have all asked their questions, Kathleen stands up and says, “No more questions from me. But I do want to commend you all on how quickly this has come together through your use of industry standard practices to guide your architecture. Because of this team’s dedication to using standards for structuring our work, we are beginning to build a strong Architecture Community of Practice.”

A couple of weeks later, Kathleen is going through the latest iteration of the architecture. She and her team had developed a list of stakeholders as part of the Architecture Vision phase. In the earlier iteration, they had mostly looked at key stakeholders to get the definition of the MVP going. Based on stakeholder input, they had then developed the different architectures of the TOGAF ADM. In doing so, they had been able to build an Architecture Runway that gave enough guidance to the Development teams to get them started. Before Kathleen knows it, the first demos are being given.

The stream-aligned teams are actually deploying the first version of the products related to the Digital Customer Intimacy strategic theme to production, and the Platform team [10] is ready to deliver the first version of the Big Data platform. In fact, the Enabling team they formed to build the first version of the Continuous Integration/Continuous Delivery (CI/CD) pipeline is now becoming obsolete; the CI/CD pipeline is in use and has been adopted by the stream-aligned teams, who are supported by a Platform team for ongoing development. Kathleen knows they can soon start looking at other areas to support the stream-aligned teams; for example, the automation of monitoring and configuration management activities.

All of this shows Kathleen that it is time for her and her team to start working on the next iteration of the architecture. Two weeks ago, they had started to develop the next set of features and enablers so the Architecture Runway would be long enough for the various teams to continue producing the results required.

Kathleen is very pleased with the results of the team: models have been created using the ArchiMate modeling language, the diagrams and the information are stored centrally, collaboration among the teams is increasing, they have a robust Architecture Repository, and the architecture process seems to be working as intended.

After giving the go-ahead to start socializing the results with the product owners and preparing the input for the Development teams in the next planning cycle, Kathleen decides to finish the day off by looking into any open items in her inbox and notices an automated email from the Portfolio Management tool about an approval needing her attention.

The email is to request an approval for additional budget from Chris, who is supporting the work of the Big Data team. Normally these are minor things and, given she is in a good mood, she decides to also make Chris and the Big Data team happy and approves the request instantly, using the button in the email.

Two days later she gets a calendar invite from Dick. She opens it and reads the text in it.

“Hi Kathleen. Great progress on the Digital Customer Intimacy strategy. I am getting good feedback from the business. Seems like they are starting to see us as a partner, not as a cost center.”

Kathleen smiles; getting such feedback is why she is doing what she is doing.

The note from Dick continues, “I do have a small issue. I got an email to approve a budget item in the Portfolio Management tool, which is odd, since I already gave approval. It seems the request is from the Big Data team, for an additional investment of $2 million. Apparently, this pushed us over the limit of the original investment decision, which is why it came to me. As I’m sure you can imagine, I need know to more about this before I release additional budget. We are making great progress, but it should not be at any cost. It will need to be justified by the expected result and its value to the business. It looks like you gave the approval for this request. Please come by first thing tomorrow morning to explain the details to me. See you in my office, thanks. Regards, Dick.”

Kathleen looks at her screen without knowing what to think. $2 million? Had she approved that? Kathleen opens the Portfolio Management tool and starts looking for the budget request of $2 million. Within a few minutes she finds it and is horrified to see it contains her approval. Stupid email button. She makes a mental note to drive a change in the tool, so the email contains a bit more detail on the request. Never again does she want to make the same mistake of approving without knowing the details.

Dropping everything else, Kathleen starts working on why this investment is required. After all, Dick is expecting an answer first thing tomorrow. She walks over to Carl’s desk and finds him working on some of the details of the exchange of information between the Big Data platform and the IoT system.

“Hi Carl, I need your help on something related to a budget request from Chris. Let’s go and have a coffee.”

Kathleen explains Dick’s expectations of her for the meeting the next day.

“So, you can only imagine why I need to get to the bottom of this ASAP.”

“Sure thing,” says Carl. “It is actually very simple. Chris just wanted to be prepared ahead of each of the new Digital Customer Intimacy releases. Last week we finally got to work with the stream-aligned teams and did some calculations for the ingestion of the data volume, based on the most optimistic sales projections of the Marketing team. But don’t worry; if those projections are true, our revenue will increase dramatically, and the cost will be peanuts.”

“But if the sales projections are not true, what would happen then?”

“We would then have enough capacity for a long time,” says Carl, smiling. “Great, isn’t it?”

“But why not order more capacity as we see the growth happening?”

“Well, that would not be possible. It takes four to six weeks for the systems to arrive. In fact, we are already late, so I really hope you can get the approval we need from Dick tomorrow – we need to order that hardware ASAP.”

“Hold on,” says Kathleen. “I thought we would use a public cloud for the basis of the Big Data platform! Actually, not only for this reason, also because some of the future epics we are going to implement need it for Artificial Intelligence (AI) on top of the platform, to provide trend analysis for the business and to be able to implement artificial agents.”

Carl looks worried. “Well, nobody told us that!”

“Why did we move to an on-premise solution? Who changed the decision we made on the selected technology platform?”

Carl shifts nervously in his seat. “The team that was tasked with the setup was ordered to be ready in a very short time, and the only way to make the deadline was by using the systems already available in our data center. We looked at the option to go external but, given security authorization was not yet provided, it would take too long for the team to start building, so we went to the next best alternative. We looked at all the available features and there was nothing in there indicating AI or virtual agents.”

Now Kathleen starts to be concerned. She was absolutely sure she had seen architecture policies and designs indicating this direction. Were they dropped somehow? Together, she and Carl walk back to her desk and sit down to look into the Architecture Repository. She opens up the system where the policies and the ArchiMate designs representing the Conceptual Service are stored.

“This is great material!” says Carl. “I wasn’t aware that this was around. It would’ve saved me a lot of time in preparing the details of the solution. The teams would have been fed with all the requirements and user stories they needed. I wonder what else has been missed?”

For the next three hours they work on how to remediate the situation of the technical debt^[5] that has been created by using an internal system. Luckily, it is possible to move the platform to a public implementation. It will cost some rework, but there is time so it will not block the go-live. They will have to delay some of the features planned for the next sprint and when they consult with the Product Owner and Scrum Master of the Big Data team to explain the situation, they agree to make a change in priority and ensure all stakeholders are informed. Immediately following this, Kathleen makes sure the Big Data team is reinforced with a security expert, so all the necessary precautions are taken.

When she gets home, she has a quick dinner with her family and then excuses herself to prepare for her meeting with Dick the next morning. She had managed to keep the damage to a minimum, but still, it would have been so much better if it had been prevented. At least she can report there is no need to invest an additional $2 million, but she still wanted to have the details ready.

The next morning, she gets up very early to be on time. Dick is an early starter and she does not want to keep him waiting. Leaving Sven to take care of the kids, she drives to work and goes straight to Dick’s office, arriving at 7:00 am.

“Good morning Kathleen, good to see you so early. Shall we get into the topic of the additional budget straightaway?”

For the next 20 minutes, Kathleen explains to Dick what has happened and how she and Carl managed to steer away from the additional budget. “I’m really sorry for this. I didn’t manage to catch it in time and it’s now causing delays in the release of some of the wanted features, but the team is confident they will be able to catch up over the next three to four sprints.”

Kathleen braces herself for Dick’s reaction.

“Welcome to my world,” says Dick, sounding resigned. “This is something that happens to me all the time. We make a decision, and nowadays better informed and much faster than before, but we still run into issues that, once investigated, could have been prevented. I am getting annoyed with people telling me ‘If only I had known this before’ and, frankly, in some cases, it seems to be creating a ‘not invented here’ culture.”

He sighs deeply. “As a result, I have to constantly tell the business we need more money and that is causing a lot of discussion. It keeps us from being seen as a trustworthy partner that has our act together.”

Dick gets up and walks over to the window. “But I am glad,” he continues, looking back at Kathleen, “that we were able to catch it earlier this time and that you managed to get a solution quicker, but still. We need to look into how to institutionalize a more proactive way of working; a way to be able to have information presented at the place and time it is required. Just like you did with the Strategy to Portfolio stuff you keep mentioning is working out so well.”

“I think,” Kathleen says, with a sudden realization, “that there is another broken value stream. I know we are storing the necessary information on policies in our Enterprise Architecture tooling, but when I showed it to Carl yesterday – he’s my lead Solution Architect – it looked like he was seeing it for the first time.”

“What do you mean? Is there something we need to change in the Enterprise Architecture toolset? I thought we had this ironed out?”

“No, not the Enterprise Architecture toolset. In addition to the Strategy to Portfolio value stream, the IT4IT Reference Architecture has three other value streams. Perhaps there’s something in one of those. I’ll start looking into it. I planned to anyway, but it was never possible given all the other more important things to do.”

“Well go figure!” says Dick, shaking his head. “We might have had a solution at hand all this time. Let me know what you can find out quickly.”

Back at her desk, Kathleen studies Figure 5 again, the IT4IT Reference Architecture, and her attention is drawn to the Requirement to Deploy value stream. Initially she had dismissed it, because the organization was using Scrum as part of the Development teams, and she did not see anything that indicated Scrum. But now that she looks more closely into the value stream, she notices the model is not specifically built for just waterfall or Scrum development. It is agnostic to the type of development process, and what’s more important to her is the fact that there are a number of connections to the Strategy to Portfolio value stream.

According to the IT4IT Standard, the “Product Portfolio” links to the “Product Backlog”, allowing the information maintained by the Enterprise Architecture team, like the strategic themes and the Architecture Roadmap Items, to be shared as part of the input used to develop the solution. This means the Architecture Roadmap Items can drive the prioritization in development and strategic themes can be used to align the different products being developed into the value streams. Next to this link, the “Policies” are linked to “Requirements”, which means the Enterprise Architecture policies can become non-functional requirements. These two links between the Strategy to Portfolio value stream and the Requirement to Deploy value stream will reduce the risk of important decisions getting lost between the different parts of the organization. Interestingly enough, this also allows information to flow back, informing the architects of how much of the policies, strategic themes, and the Architecture Roadmap actually is implemented. The last link is through the “Digital Product”, which defines the digital products that the organization will deliver and how they relate to each other, forming the “Product Portfolio”. By linking the “Digital Product” into the “Product Design”, the “Digital Product” defines the guardrails of the design of each part of the product and at the same time allows the Enterprise Architects to understand what from the digital products actually has been designed and developed.

She decides to first check with Carl and walks over to his desk.

“Hi Carl, I just got back from my meeting with Dick and I was wondering if you can help me with something?”

Carl looks up from his work with a wary smile. “Not sure. But tell me what you need, so I can tell you if I can help you with it.”

Kathleen explains the request she got from Dick to look into improving the sharing of information, so it prevents the creation of technical debt before the development is even started. “So, can you show me what tool you are using to create the software designs?”

“Yes!” says Carl cheerfully. “That, I certainly can tell you. It is our UML^® modeling tool. It is actually shared across the different teams, and it has the links to the backlog systems. It’s great. We Solution Architects can see each other’s work and when one team makes a change, it helps us to find out what other parts of the system might be impacted. It has helped us tremendously with the Architecture Runway for our digital initiative.”

“I see. That’s great, but where do you start with the creation of the UML models?”

Carl answers quickly. “Oh, we just read the documents that are provided to us after the decision to invest is made and start creating the necessary designs. We try to keep it to a minimum at the start and use a sprint approach to develop the details. We are using a just-in-time approach, so we have maximum flexibility when things need to be adjusted throughout the development.”

“So once the initial Idea is read, from there on the development continues in an Agile way?”

“Yes. Great, isn’t it?” says Carl proudly. “Maximum flexibility, just as the business needs.”

Kathleen pushes on. “And does anybody update these changes in the corresponding Enterprise Architecture models? So the Architecture Repository is up-to-date and consistent across the different models?”

Carl shrugs. “You mean the ArchiMate models you showed me yesterday? Nope. As I said, I do not have access to those models and, as a result, I personally have never done any updates. But to be honest, I don’t want to spend time updating all kinds of models.”

Kathleen agrees with this last statement, but she now also knows how to fix this broken communication. Besides the ArchiMate models within the Enterprise Architecture team, the UML models should be represented within the Architecture Repository, preferably in a way that allows the designers of software to have access to the designs of the Enterprise Architecture team and link their diagrams, so changes will be flagged on both ends. Certainly, with the new way of working in iterations, it is important to be able to have traceability between the Software Design and the Enterprise Architecture.

“So, if we want to fix this, we need to make sure we do not also create more work. But what I don’t understand is, why are the results not shared back?”

“Sorry, but please don’t get me started!” says Carl, feeling frustrated. “We are trying to do this. Every sprint ends with a demo, and every four sprints we host a joint planning meeting, and in between we have the Architecture Alignment meetings. For all of these events we invite all stakeholders, but nobody from Enterprise Architecture ever turns up. If you ask me, that’s an easy fix, but who am I to say?”

Kathleen thinks back to Chris and Jamar’s comments a few weeks ago about making sure the architects are giving the developers a good Architecture Runway. And also, the architecture group really needs to work on their relationship with the DevOps team. The last thing they want is to be seen as a bottleneck, but they do want to ensure a quality MVP that does not have to be reworked over and over because the developers did not understand the environmental constraints. This is exactly the kind of thing they were talking about and she feels ashamed. She has seen the invites but has always de-prioritized them. The planning cycle normally takes far too long for her liking; the alignment meetings spend too much time focused on technology details, and the demos seem to always fall at times when there is something more important to attend to.

“You’re right,” she says, genuinely. “That needs to change. I am sorry I never attended. I will start to attend and will make sure the other Enterprise Architects join as well. However, we should also make sure information in the Enterprise Architecture Management tool and in the Software Design tool is connected, so information can flow between them.”

Armed with this knowledge, Kathleen begins to create an overview of what needs to be done. First and foremost, the teams need to improve collaboration. From the start they had been creating stream-aligned teams based on cross-functional teams, but they had been keeping the architects as an outside element; not as part of the teams around the value streams themselves, but outside as a kind of staff function, which basically meant the Enterprise Architecture team was still operating in a silo. Kind of old-style thinking. All the work is happening around the value streams, so the architects need to be aligned to the value streams. A good starting point is to get involved in the ceremonies of the stream-aligned teams. Together with the Product Manager, she agrees that the Enterprise Architects are required at the Architecture Alignment meeting, but it is equally important for the Enterprise Architects to attend the sprint demos, retrospectives, and the backlog grooming sessions. This would allow the architects to learn first-hand what is not working and what changes would help the organization most. Secondly, the integration between the Enterprise Architecture Management tool and the Software Design tool needs to be created so diagrams can be shared between them, enhancing the Architecture Repository. As a third item, the Policy system needs to be connected with the Requirements system.

She validates the result with Carl and finds there is more than one Software Design tool, but they share a central repository. So, instead of integrating each tool, they decide to integrate the Enterprise Architecture Management tool with the central repository.

The next day, Kathleen initiates a new Idea in the portfolio management system and gives Dick the heads up that the Idea will be coming up for approval soon.

The Idea gets funded and over the course of the next two weeks, the integrations are made. The Architecture Alignment meeting is attended by the Enterprise Architecture team members, and they grudgingly start to attend the demos. Unfortunately, in the beginning, the new focus on collaboration identifies a number of other similar issues, all of which went unnoticed before but once identified shine a light on why it was so slow to get Ideas delivered quickly in the past. Some of these issues create the need for refactoring, which makes business leaders start grumbling and turning a sharper focus on the architects and other technology leaders, which is uncomfortable. But, after six weeks, these issues are addressed and both the hindrances and the grumblings start to disappear. More importantly, through these interactions, the Enterprise Architecture team is getting more and more involved in the actual development, including being involved in usability testing and the communication on big releases. Strange how these things change the perception of your role.

Kathleen makes a mental note to herself to adjust the initiative’s resource allocation to include architects in the sprint planning sessions. I may need to adjust the roadmap a bit due to these last couple of surprises, she thinks. The good thing about getting all these inefficiencies in our product development workflows ironed out now, though, is that it creates early feedback loops so our next iterations of the digital product will run more smoothly. We are transforming into a learning organization.

“But how, please tell me, can we develop the marketing strategy for our new product if we are not able to extract this data from the B.L.O.S.?”

Kathleen and Amy stop their conversation and look across the canteen to find the source of this cry for help. It is Ben Cohen, the new Business Analyst responsible for marketing the digital products, and he is clearly upset. He is talking to Hans Pickle and both men are showing signs of a heated debate.

“First of all,” says Hans angrily, beginning to clench his fists, “it is not called the B.L.O.S.” He stops, takes a deep breath and lets it out slowly. “It is the Prolongation Application,” he says carefully, trying to manage his anger through gritted teeth. “I will forgive you this mistake because you are new.” He looks directly at Ben. “But let me explain this to you one more time. My team is responsible for the Prolongation Application and its replacement. Given the importance of this application to the survival of this company, I hope I do not have to explain to you that we need to control carefully what the team is working on. In the light of all other work, your request is not important enough for me to prioritize, so at this moment in time I do not care about your small problem.” He gets up, standing right over Ben, who can only stare up at him in astonishment at this tirade. “You figure it out,” says Hans, pointing at Ben. “And come back when we have released the replacement system. I simply do not have enough resources in my team to facilitate both the replacement and all the ad hoc changes to the current system.”

With a triumphant smile, Hans walks out of the canteen. Ben shakes his head in disbelief. He brushes himself down and, trying to ignore the concerned looks of others sitting nearby, he gets up and walks over to the counter to get something to eat.

“Well, they don’t seem to be in agreement,” says Amy. “I feel sorry for Ben, he just started in this new position. You know Hans is under pressure? He promised the replacement of the B.L.O.S. would have been completed months ago but every time the acceptance fails. I believe he is going to try a third attempt at the end of this month.”

“I know,” says Kathleen. “We’ve had our share of complaints from Hans. I’ve just had to replace the architect in his team now for the second time. He blames us for not being able to design a replacement architecture. And with every failed go-live he shouts this to anybody who will listen. Some of my team even refuse to go back there.”

“You know, all I hear about his team is that the atmosphere is below zero; nobody wants to be there. He seems to be blaming everybody except himself.”

“Hi Ben, how are you doing? Come and join us for lunch?” Amy leans over to catch Ben’s eye as he passes their table.

“Oh, sure. Thanks,” says Ben, gratefully. He grabs an empty chair, pulls it over, and sits down quickly.

“Have you met Kathleen, our Chief Architect?” Amy asks.

Ben and Kathleen introduce themselves to each other.

“Ben,” says Amy, with a glance toward Kathleen, “it seems you and Hans are not getting along very well?”

“Don’t get me started,” says Ben, shaking his head. “Everybody is so cooperative and helpful, and I really enjoy working for this company, but this is now the fourth time he simply refuses to even listen to my request. I understand the need to manage demand, but it does seem that when it comes to his precious B.L.O.S. – oh sorry, Prolongation Application – nothing can be done. And everybody needs to wait on this replacement system. I can tell you, our colleagues who need to accept the replacement system are indicating that the system is still not complete. Every test cycle they find something else the current Prolongation system is doing that nobody could have guessed before, simply because it has not been documented properly. I am afraid it will be like this for a long time.”

“Sorry, I have to ask,” says Kathleen, “but do you know why we call it the B.L.O.S.?”

“Nope, I have no clue. But that’s what everybody calls it, isn’t it?”

“Well, that is true. Apart from Hans everybody refers to it as the B.L.O.S. It stands for Big Ludicrous Old System, which is exactly what it is. Not its official name, obviously, but it stuck. And honestly, I do not envy Hans. He has the task of replacing this legacy system, which is connected to so many processes that it is too big to fail and all attempts to dismantle the application have failed to deliver. I think Hans wanted to build a career on it.”

Ben smiles for the first time since he sat down. “Ah, that explains why he keeps telling me it is not called the B.L.O.S.!”

“But if it’s so hard,” asks Amy, “why are we replacing the application?”

“Because we’re not able to adjust it quickly enough, it is becoming a liability for the organization and needs to be replaced,” says Kathleen.

“Oh, I do understand a change is required,” says Amy, “but is the big-bang approach in replacement really necessary?”

“Well, I think so. How else would you replace an application?”

“Let me rephrase the question,” says Amy. She turns to Ben. “Can you tell us what the actual request is that you have for the B.L.O.S.?”

“All I want is a new report. Not very fancy, but information that helps us in targeting the right audience for an upsell program we have been asked to prepare.”

“And does this require new functionality in the applications?”

“I don’t think so,” says Ben. “The data is available in the application; it’s just all over the place and we would need to combine data from different screens to extract the information. It is too cumbersome to do manually.”

“But that does not even require a change in the application!” says Kathleen. “We just need to have the data available in our reporting engine.”

Ben turns to Kathleen. “Exactly, but that’s also the reason for my issue. In this case, such a request means the data extract needs to be written in the application. There is no API to extract data using a query, otherwise we would have been doing this ourselves.”

“Is this data very volatile?” says Kathleen, excitedly. “Does it change very quickly, or can you work with data up to a day old?”

“Sure, as long as the data is not months old, we can work with it,” says Ben.

“Then you should be able to work with the generic data backup we are making on a daily basis. We created this a while back because of the regulator forcing us to have a backup for all critical systems for business continuity. So, I suggest we check with our Risk Management team to see if that data contains what you need.”

“OK, that would be great,” says Ben. “And I can guarantee, there are more people in this organization with similar requests related to data from the B.L.O.S., so I guess this approach could apply in more situations.”

“Exactly my point,” says Amy. “It is not always possible or the best approach to try to replace something this big, especially if replacing it has already failed a number of times. As I see it, sometimes you need to slowly strangle something in order to create breathing room. I suggest you look up the “Strangler-Fig-Pattern” [20] and An Agile Approach to Legacy Systems, by Stevenson and Pols [21] because I have a feeling they will be useful.”

Kathleen and Ben agree to put a small set of user stories on the team backlog of the team with the skills to work with the backup system. The news of the alternative approach spreads quickly, and more and more requests come in. After reading the articles recommended by Amy, Kathleen and her team start to define additional solutions to help the organization without touching the B.L.O.S. application. One option is to use a concept called “event interception”, which is a method for keeping transaction data in the legacy application and the new application in sync.

Six weeks later, the Data Warehouse and Business Intelligence work streams have made significant progress. The refactoring is completed and Release 1.0 of the new Digital Customer Intimacy strategy is ready for a go-live into production. Effectively, the new way of collaborating between architects and the Development team is well accepted and largely in use. The Enterprise Architecture team has been involved in the development of the data warehouse application and is being informed of the test results. This application is one of the key digital products for ArchiSurance because it will give executive leadership information about our customers concerning their likes and dislikes. It will also provide analytics on customer demographics to help determine the best way to deliver services to the customer base.

Craig Evans, the Product Owner for the data warehouse project, receives an email from the Release team confirming the test report has been approved and the Release Package is ready for deployment. He is pleased with the results and plans to contact the team immediately to launch the deployment to the cloud environment. Craig has been watching the emergence of a health crisis caused by a new virus, anxiously wondering what might happen if it continues to spread around the world. In addition to worrying about humanity in general, he’s been thinking about all the negative impacts that might be passed to customers, their businesses, and to all the people they employ and serve. What could he recommend now that would make the data warehouse application deployment more resilient for global use and to anticipate larger-scale use?

Only three weeks later, many digital technology employees are confined at home because of the global scale of the pandemic, except the teams in charge of the maintenance of the data centers. Kathleen is working from home with her husband and their two children, sharing her time between the children’s education and the management of the Enterprise Architecture team.

Kathleen is happy to note that the impact of the lockdown hasn’t disrupted work for the teams. The new way of working allows them to simply change to remote locations without losing a heartbeat. As she eats breakfast, realizing how relaxing it is to eat with the family every morning, her phone rings. It is not a number she recognizes, but in these trying times where work life is upside down, she now answers all calls.

“Hi Kathleen, this is Jasmine Williams from Customer Relations. I’m so sorry to disturb you this early, but we have a major incident going on with a lot of customers impacted. I’m setting up a war room and I need somebody from the Enterprise Architecture team to participate.”

“Of course,” says Kathleen, aware from the tone in Jasmine’s voice that the problem is serious. “But could you just tell me a little more about the problem, so I can work out who will be the best person to help you?”

“Sure. Since yesterday, we’ve been receiving lots of calls and emails in Customer Support from people who can’t access their ArchiSurance account with their mobile application. We already checked the changes that went through yesterday and the only one was the deployment of the new data warehouse application. However, customers do not have direct access to this application, so we need to investigate more deeply to find out whether and how that might have been the cause of this incident.”

Kathleen thinks about the Digital Customer Intimacy roadmap and finally answers Jasmine.

“I’ll ask Jamar Johnson. He is our IoT expert and the Mobile Application and IoT teams recently began working together.”

“That sounds great, Kathleen. Thank you.”

Kathleen’s hunch was right. Less than 15 minutes after Jamar Johnson joined the virtual war room, they discover that the mobile app had been updated to be compliant with the new Identity and Access Management (IAM) system that is now required for the security of IoT devices, which are now connected to the updated data warehouse system. Jasmine calls Kathleen to give her feedback on what they found.

“Good job, Jasmine!” says Kathleen, after hearing the cause of the incident. “But why did we authorize the deployment of the data warehouse application in that case?”

“The Enterprise Architecture team has been involved in the testing, but not in the final deployment,” replies Jasmine. “The architects are also invited to the Change Advisory Board (CAB), but the CAB is only concerned with Requests for Change (RFCs) that are registered in their system and which go into our own data centers. In this instance, the data warehouse application was in a public cloud, so it was missed by the CAB.”

Kathleen now remembers the new team is using a fully automated CI/CD pipeline. She remembers how proud everybody was when they did the first fully automated deployment to production. Since then, anybody in the team could submit code or other changes to production, as long as it passed all the testing. This basically bypasses the whole CAB; something she had not considered.

“In this case,” says Jasmine, “the decision to deploy the MVP of the data warehouse system, including the new IAM system and mobile app was made by Craig Evans, the Product Owner. Given that the pipeline itself was showing green, and all new and updated systems were working as designed, there was no indication of anything wrong, so the deployment itself was successful. Unfortunately, nobody involved in the deployment was aware that some of the oldest versions of the mobile app are still in use and as a consequence it stopped working. Perhaps, if the architects or the CAB had been informed of the deployment, they could have prevented the situation. However, as you know the architects were not informed up-front, and nor was anyone in the CAB aware of the deployment because the deployment was made to our public cloud environment.”

“OK,” says Kathleen, “so, that is something we need to look at again. It sounds like we still need to get our architects embedded with the Agile teams instead of working in our own silos. But what’s been decided to resolve the issue at hand? What’s the proposed resolution?”

“The problem is we do not know which customers are using the mobile app and which version they have installed. The app is available for free on different app stores and we have no feedback on who is downloading and installing the app. The only solution we have now is to send an email to all our customers to inform them that they need to update their mobile app if they are using it.”

Kathleen agrees and asks if Jasmine can get Corporate Communications involved to ensure the email is sent out in a professional manner.

“Yes,” says Jasmine. “That’s a good idea and should be pretty easy for them to do.”

Kathleen hangs up the phone as Sven steps into the room.

“I just finished helping the kids with their mathematics lesson, it’s your turn now. Oh, wait, are you ok? You seem upset. What just happened?”

Kathleen explains the cause of the major incident they had and how they are going to solve it.

“I thought you implemented that IT4IT Reference Architecture to get more transparency into the flow of products and make the gaps visible,” says Sven. “What happened?”

“We didn’t implement all of the IT4IT Standard, only the parts of it that would help solve some of our immediate issues. But you’re right, I’ll have a look at the IT4IT Reference Architecture again to see if this can be resolved. I have more time now that the next iteration is on hold during the pandemic confinement.”

The next day Kathleen takes a closer look at the IT4IT specification and especially the “Request to Fulfill” value stream (Figure 9); the one that addresses the delivery and consumption of services.

She discovers that the IT4IT Standard describes how to build catalog offerings that allow consumers to order a service that is executed through to the fulfillment of the order. More interesting is the subscription mechanism proposed by the standard. With this in place, ArchiSurance customers could order the mobile app service, and as soon as the app is installed they could keep track of their subscription to the service through the Order functional component. This would make it easy to know which customer is using the mobile service and which app-version they are using. The Order could be placed through the web portal already in use by customers. Information on updates could be delivered directly to customers via the portal whenever catalogs are updated with a newer version of their app. It is even possible, with the right monitoring in place, to follow the usage of the service for each customer.

Another interesting aspect she found by reading further into the IT4IT Standard documentation is that the same ordering mechanism can also be used by the staff. It dawns on Kathleen that the services consumed by people for things like a cloud infrastructure or an application deployment in the cloud could also be managed the same way as customer requests for business applications. If ArchiSurance had already put this in place, it would have been possible to have an approval workflow that included routing the approval to the Enterprise Architecture team.

Kathleen also notices the Fulfillment Orchestration component, which orchestrates the delivery of the various orders amongst fulfillment automation systems. The interesting part here is that it is triggered by a change. That is not something they had ever considered. What if the CI/CD pipeline could register a change automatically every time a change is going to production? That would also solve the issue of the CAB not being aware of changes. It might even be possible to tie releases of the CI/CD pipeline to a change that could be submitted for approval by the CAB even before it is being developed. In that way, the CAB would be able to perform its risk analysis, without stopping any deployment. Kathleen decides to look at that part at a later stage. First, they need to fix the ability to track requests.

Feeling motivated, Kathleen starts to build a course of action for what needs to be done to implement the subscription model.

Every service offering, she realizes as she types, would need to have the following data objects tracked: Service Offer, Order, and Subscription. And every Fulfillment Orchestration component, including the new CI/CD pipelines, would need to register a standard change, identifying the change they had made to production.

In less than half an hour, she has a “good enough” model, so she opens a web meeting and invites Philip Potter and Terri Nichols, the architects who have been working on the value stream stage “Serve Customers”, to join her. She explains her new Idea and tests its feasibility with them. They both really like the Idea and Philip confirms that the service management system they are currently using can be updated to implement the subscription mechanism and has an API to allow the CI/CD pipeline to open and process a change. Furthermore, Terri says that she is fine with interfacing the web portal with the service management system.

The following day, Kathleen logs into the portfolio management system from home and submits two new Ideas. First, to implement the subscription mechanism through the web portal and second, to let CI/CD pipelines create and process a change. She points to the recent service interruption incident and its negative impact on customer satisfaction as part of the rationale.

It is agreed to fund the Ideas, and the new features are added to the appropriate team backlogs.

Four weeks later, just two weeks after the change and CAB solution have been implemented, Kathleen starts to notice an increase in the workload of the CAB. This is of course necessary to help the organization get control, but Kathleen considers this to be an anti-pattern for an Agile organization. It creates a stage gate with the risk of delaying work and, suddenly, architecture decisions are validated as part of the CAB. To address the issue, she organizes a web meeting with her team to address what the next steps should be to reduce the risk she had identified.

Together they discuss the topic in detail and conclude that they have to find a way to allow the teams to be able to make decisions autonomously, but at the same time give the Enterprise Architecture team the right to step in. For this, they will need two things: the ability to see what is coming, and an understanding of why decisions were made.

The Enterprise Architecture team needs to find a more balanced approach to gain an understanding of why decisions were made, using Architecture Decision Records (ADRs) [22] rather than forcing everybody to submit their decisions for approval. The ADRs will be used by the Agile teams to record their decisions and then made available to the Enterprise Architecture team who can then validate amongst themselves whether these decisions are in line with the intended architecture. If they are not, a discussion can be started to see what can be done, removing the need for architecture decision validation as part of the CAB approval.

Gaining an ability to see what is coming, however, requires the team to think about how to present the planning of changes as agreed by the QBR [23]. The QBR should also be one of the approaches considered for providing governance in the transformed organization.

“I guess the next steps for us will be to begin migration planning,” says Kathleen. “I will have Tony set up some meetings for next week. We can get the enhancements of the Architecture Roadmap established that we have been talking about, so it can support the organization with migration planning. I would like Carl to lead this effort so that the way we document the migration becomes part of the Architecture Community of Practice.”

Everyone nods in agreement and Nick reminds Kathleen that the team has been looking at some standard formats for roadmaps and is just about ready to make a recommendation.

“That sounds wonderful, I can’t wait to see what the team comes up with!”

Kathleen notices that the TOGAF ADM itself is perfectly fit to be used to drive architecture development in an iterative way that is compatible with supporting Agile solution development teams. However, it certainly does not help to use the jargon from the ADM steps when simply wanting to implement a collaborative way of working with the Agile development teams. Moreover, creating the architecture iteratively ensures that architecture input is provided to the Agile teams when needed, without creating BDUF. To see the details of what is presented by Carl, how it is documented, and what transpires in this meeting, see Bonus Section E.

Friday finally rolls around and, for the first time in months, Kathleen feels as though she can completely relax. It had taken just ten days to implement the changes to make sure all requests were approved, and the CAB is now fully aware of all changes from the stream-aligned teams going into production. In the following two months, they had managed to get four releases into production without major incidents. Even the Governance, Risk, and Compliance (GRC) team had started to use the Idea system to get security systems in place.

With summer in the air, Sven and Kathleen decide to take the next week off and go up to their cabin in the mountains. They give the kids the choice to come to the cabin with them for hiking and campfires or stay with Grandma and Grandpa. The unreliable cell phone service and absence of a TV at the cabin causes the kids to elect to stay in town at their grandparents’ house for swimming, playing with their two dogs, and eating Grandma’s famous home-baked treats. Over the last several weeks, Kathleen and her family of four had been staying in quarantine together in their small house full-time due to the global pandemic, following government warnings to shelter at home. After working at home and home-schooling the kids, both Sven and Kathleen have had enough “family bonding” and are relishing the thought of getting out of town, just the two of them.

As she and Sven start the two-hour drive to the cabin in the rental car from the airport, Kathleen looks out the window and reflects on all that has happened over the last year. She and her team had worked hard to get the Customer Digital Intimacy initiative going and to get the whole team aligned across the IT4IT value streams. As the digital products started to become operational, the new way of working started to become routine, and the new ceremonies were becoming the norm, Kathleen began to feel she could take some time off. Sven begged her not to bring her laptop and to take a rare break from her addiction to work, but she felt she would be more relaxed if she had it with her “just in case”. She promised Sven she would hide it from view on a shelf in the front hall closet.

For the first couple of days at the cabin, Sven had to implore her to stop walking around the property with her arm outstretched holding her phone out in front of her, trying to get cellular service for long enough to check her emails. But, by Tuesday, she started to relax and from then on, when they went on their hiking or canoe trips, she left her phone behind and was able to enjoy nature and the beautiful surroundings with Sven for the rest of their week together.

On Sunday, Sven drives them to the rental car drop-off center.

“It is a shame we have to go back already,” says Kathleen, with a sigh. “I wasn’t aware of just how much I needed this trip to unwind. Thanks for making me take time off and encouraging me to not think about work at all.”

Just as Kathleen finishes speaking, her phone rings. She recognizes the number immediately as one from the office and without hesitation she declines the call. Whatever this is, she thinks, it can wait. It’s already the end of the day, and she will be back in the office early on Monday. She knows she will check for messages when they arrive home anyway.

Within one minute, the phone rings again. Same number. Curious about what the fire could be, she apologizes to Sven and decides to answer the call. Sven shrugs, all too familiar with her choices, and motions for her to get out of the rental car and follow him to the shuttle bus that will take them to the airport departure gates.

“Hi Kathleen, Nick here.”

Nick has been covering her duties during her absence. Kathleen hears the anxiety in his voice.

“Sorry I have to disturb you, but I really need to pick your brain. Starting this afternoon, we are getting issues with the operation of the new digital products platform, where we host our digital products. Our customers are experiencing intermittent issues with accessing their own information and every other new request is not getting through. To make it worse, the Operations team is not able to get anything out of their monitoring systems, so they are logging in manually to individual servers and containers and using their tribal knowledge of the environment to do triage without any centralized information. The most annoying issue is that, once we have solved something, a few hours later our change seems to be rolled back, even though we have stopped all deployments. This means we are basically back to reactive mode only, which makes for a very slow triage speed. They’re basically trying to fly a plane when all the instruments have gone dark.”

Trying to hear Nick over the noise of the rental car shuttle bus and making a face to Sven that she hopes conveys, “Sorry about this”, she listens closely to Nick as he walks her through the details on their triage efforts.

“To solve the issues,” Nick continues nervously, “I have established two incident resolution swarms as we agreed – one for the product issue and one for the monitoring issue. We have checked all deployments done by the teams in the past 48 hours, but so far this has not revealed anything. We are at the end of our options of what to look for, so I wanted to check with you if you could remember anything we might have missed. We have not put anything into production in the last 24 hours!”

The longer the conversation goes on, it is clear the teams have been doing a great job in identifying what the problem is using the approach they had tested out so much. Kathleen feels gratified by the willingness of the organization to embrace all the new ways of working. However, even with everything in place, they were somehow still failing to identify the root cause.

Kathleen is grateful to Sven as he gently moves her like a robot through the process of checking in for their flights, and ruefully watches as he handles all their luggage by himself.

“OK,” says Kathleen. “Can you get the list of change requests that have been accepted in the past three weeks?”

There is a pause on the other end of the line. “Well … We know all changes from the stream-aligned teams and none of them indicated any issues. But apparently, given the new way of working with the automation of creating changes for the CAB, the original formal change process has been dropped completely and we have identified there have been changes implemented outside the automated approach.”

“OK, that is not what I expected, clearly something we missed.” Kathleen sounds worried. “But how do we know what other changes have been implemented?”

“It seems the Operations team have been organizing themselves around the Agile way of working as well. They have started to adopt site reliability engineering^[6] and currently they have reorganized into four teams to carry out the development of scripts, monitors, and other types of automation, trying to keep up with the rate of change that is hitting them. A big win has been the formation of Communities of Practice,^[7] which unite professionals at ArchiSurance with shared interests in industry best practices, like automation – for managing operations in a scalable, reliable, and highly automated fashion. If they hadn’t done this, it would have been an issue for them to support the new digital products platform.”

Without letting Kathleen get in a word edgeways, Nick continues. “I know – before you say anything – it was also a surprise to me that they had implemented new things in production, even though it had nothing to do with the functionality of the platform itself. However, they have been doing a great job. For example, there is now a new discovery and monitoring environment over the last four weeks, rolling out discovery agents to all platforms and automatically assigning the appropriate monitors to them. Unfortunately, starting this morning, both the discovery and the monitoring failed to report centrally.”

Kathleen starts to feel a stone in her stomach. This means they are no longer really able to understand what is going on in production. The first set of deployments was done without any problem; all the teams had aligned themselves on the releases and the new development techniques made the teams operate with relative independence. So why did this hit them so hard? She really needs to look into this when she gets back in the office. She also starts to feel nervous that there might be even more that she and her team are not aware of in production, given that there were also deployments done outside of her visibility as an architect.

“Nick, can you do me a favor and check with the Portfolio Management team and ask them what approvals have been given to which investments? Perhaps there is an investment approved that we have missed? See if you can learn from them what was supposed to go into production in the past two weeks. OK?”

Sven taps Kathleen on the shoulder. “If you really want to make our flight, then we have to go through security right now.”

Kathleen nods. “I really have to go right now, but I’ll call you when I’m sitting at the departure gate. Can you have the list ready by then?”

Nick answers in the affirmative and hangs up.

As she moves through the security process, Kathleen is reminded how very much she dislikes the policies implemented at airports, despite knowing why they are needed.

“Unfortunately,” she says, turning to Sven, “security is ubiquitous – it touches us all whether we like it or not and –”

Kathleen stops talking mid-sentence. Sven looks at her, puzzled. “Why the funny face? Yes, security practices are unpleasant, but very necessary. Why are you making a big deal out of it now?”

Kathleen’s brain has shifted into a higher gear and she ignores Sven completely. She suddenly remembers that the Security team recently released a new version of their security platform. As part of that release a new set of policies was supposed to be deployed into production. The Enterprise Architecture team has been asked to help to identify the set of systems that would be covered by these policies so that they could be tuned to make sure production would not be impacted.

After the initial implementation, thereafter, the Security team would be able to apply the necessary policies to each of the systems. But the Security team took it one step further. The system had its own AI functionality and was able to apply the necessary changes to systems in production automatically based on the applicable policies. They had identified all mission-critical systems and had also agreed to apply the highest level of security to all machines associated to those mission-critical systems, including those that would be discovered in the future, beyond these early identified systems. Since all mission-critical systems had been included, nobody would expect any major issues as a result of this approach. However, given that the Enterprise Architecture team was not even aware of the changes done by the Operations teams, the new monitoring systems were most likely not part of one of the identified mission-critical systems.

Kathleen starts to rush through the airport security process, dragging a confused Sven with her. She has to give Nick a call as soon as possible. Most likely it was the security system that was blocking the monitoring system and its AI functionality was constantly rolling back the changes made by the Operations team. Once she finally finds an open seat in the already crowded lounge, she quickly dials Nick’s number.

“It’s the new security system!!” they both say in unison when Nick picks up the phone.

Nick tells Kathleen that once he opened the portfolio management system, he identified that the only other change was the security system. When he reached out to the Security team, they confirmed the rollout of a number of new policies that day, including the automatic rollout of the highest level of security for new systems. They also indicated they could not figure out why the system was constantly applying the same policies over and over again and were frantically looking to see if there had been a security breach.

Kathleen and Nick agree that Nick will take care of managing the rest of the resolution, by bringing the Security team into the incident swarm.

By the time Kathleen’s plane lands, all operations have been returned to normal and the incident swarm has been dissolved. Sven had complained to her on the flight that he thought something must be wrong in her organization if they could not function without her. Although she knows he is right, and it is the result of an organization design gap that lacks cross-discipline visibility, Kathleen was actually feeling pretty happy with the way the situation had been handled. Yes, there was still the open issue of the unknown changes and the inability of the Architecture Repository to flag discrepancies with the actual production, but they were well on the way toward working together across functions. Once again, she found herself wondering if that last IT4IT value stream would be able to help her as before. However, this really was something that could wait until Monday. It was time to pick up the kids and return to their “new normal”.

After arriving at work on Monday morning, Kathleen calls for a post mortem session, so they all could learn from the incident in a safe environment. She invites the Security, Operations, and Development teams as well as her own Enterprise Architecture team, and opens with the questions: What went right? And what could we have done better?

She has her own ideas about the answers and is glad to see the outcome of the session is going in the same general direction. The team thought that what they did well was getting together so quickly, bringing in the necessary knowledge into the incident swarm and – outside of some minor adjustments to the way people are called into the swarm – they agreed it was fit-for-purpose. However, they did identify two things that could be done differently and better in the future: first, to understand the actual state of production, and second, to identify the potential impacts of changes.

Kathleen agrees to come up with a solution, indicating she would review the IT4IT value streams to see what solutions could be used.

As she expects, there is one value stream left she has not looked at: Detect to Correct. When she looks into the details of Figure 10, she comes up with a solution for both issues.

The first item is to make sure it’s possible to compare the actual state of the production environment with what is known in the Architecture Repository. To achieve this, Kathleen notices the IT4IT Reference Architecture maintains the “Actual Product Instance”, within the Configuration functional component. This Actual Product Instance data object is part of the Digital Product Backbone, and all data objects in the Digital Product Backbone have defined relationships. So, the solution is based on the information captured in the configuration management system of production, which includes the ability to discover the actual environment. The comparison can then be made with the “Desired Product Instance” which is maintained by the “Fulfillment Orchestration” component. When something is implemented in production outside of the approval process, it is picked up by discovery; but such a change would not have changed the “Desired Product Instance”, so the difference in the comparison would indicate something has changed without approval.

In order to solve this, she designs a system so that when the discovery reveals something new, it creates an Incident, assigned to the Enterprise Architecture team who can then investigate what to do with this product. Maybe not the best way, but for the time being a “good enough” solution. She makes a note to herself to look into bringing the Actual Product Instance into the Architecture Repository and bring this idea back to The Open Group IT4IT Forum; perhaps this is an idea for a future release of the standard.

The big benefit for the Enterprise Architecture team is that by implementing this closed loop, the governance of the architecture across the organization will be much easier; based on actual information stored in systems available to everybody, rather than only in architecture diagrams used by architects.

The other part of the solution is to ensure the Change component, and especially the Change data object, contains a register of changes. The creation of a Change is done from any source, including the Fulfillment Orchestration functional component. Any CI/CD tool chain would have to be integrated, not only from the stream-aligned teams, but from any team, including the Operations team. All changes, of any type need to create a record in the system, even from teams not using a CI/CD tool chain. Not to enforce a process to run, but at least to have all changes in a central repository. This would provide a consolidated view of all changes – those done manually and those done via automation. This would give future incident swarms a good overview of what has been changed.

She also decides that the people from the Operations team will become part of the Enabling team, with a focus on the digitalization of the Product Management lifecycle. Security will need to align to this as well. The big benefit Kathleen sees for the Enterprise Architecture team is that by adding this functional component, and connecting the Change to the Desired Product Instance, it is possible to track the transition states and the completeness of the target state of the architecture planning, allowing full visibility into Architecture Change Management. This will be a tremendous benefit for the coordination of releases and for the communication to employees and customers about upcoming features available for the Digital Customer Intimacy strategy.

As with the other implementations, she submits an Idea into the portfolio management system and, before she knows it, it is approved and the implementation of the integrations starts.

With the end of summer right around the corner, Kathleen’s mind wanders back to the cabin and how nice it must be up in the mountains right now. She will talk to Sven about another trip when things start winding down at work in a few months.

Pulling herself back to focus, Kathleen calls in her architects to discuss the next iteration of architecture design. Throughout the implementation of the various new products, some solutions implemented by the various teams had overlapped with existing solutions. More and more signals from the business users indicated that they were getting fed up with the constant need to work in different systems which had this overlap. It was getting harder and harder to get a good overview.

She discusses this with Dick. “That’s something that is bugging me as well,” he says, “but from a different angle. We as digital technology professionals have to constantly keep more systems up and running, so even though the new systems are more efficient in maintenance and operations, we can’t show any cost reduction back to the business, because we now have more systems, not less. I think it is time we formed a group to start driving application rationalization. Can you try to get all the stakeholders aligned and prepare a way to assess the different applications so we can decide which ones we must sustain and which ones we can retire?”

Kathleen agrees and tasks Nick to drive the application rationalization initiative. Some weeks later, Nick presents his findings to the group.

Nick starts his presentation by flashing up a slide of a Capability Map on the screen. Jokingly he says, “It is actually very simple, people! The solution to the assessment is the Capability Map. Period. Carry on. The end.” He sits back, grinning.

“But all joking aside,” he continues quickly, “what is true is that the main framework to support an assessment for application rationalization is the Capability Map.”

Over the next hour Nick explains how the map can be used to assess which applications are connected to which capability, and how a classification method along the axes of Value, Cost, and Technology could be used to score each application to identify what type of transformation would need to be done, using the 5Rs of Gartner^® [25].

“For the situation where one capability is being delivered by multiple applications, we can choose the best one(s) to sustain by selecting the one(s) with the highest scores on the three axes. For the situation where there is no application covering a necessary capability, the scoring can be used to identify which of those gaps – if any – are a priority to instantiate.”

They all agree the approach is a sensible one and Kathleen agrees that the next step is to take Nick with her to give Dick the five-minute executive summary version of it.

Before ending the meeting, Kathleen addresses the team.

“As you were talking about the application rationalization portion of your presentation, I was thinking about another gap we could fill using the IT4IT Standard. A week or so ago, I ran across an IT4IT guidance paper in The Open Group Library that gives step-by-step instructions on how to use the IT4IT Reference Architecture to rationalize your tool landscape [26]. We definitely have lots of product/service management tool duplication and redundancy across our functional organizations. In the process of building the integrations between the Enterprise Architecture tool and the Portfolio Management tools we found lots of redundancy and had to pick a primary source system for the integration. People will need to start using the source systems and quit using their disparate document collaboration sites for collecting important information. Otherwise, we are never going to have a centralized way of capturing the flow from Strategy through Operations. I will work out some instructions, which I will send out to all of you on the integrations that establish flow from Strategy to Portfolio. Furthermore, in addition to the integrations we set up, there also needs to be some criteria and governance in place for when something new is proposed for the portfolio. For example, we should never start work on something that is not directly tied to the company strategy. Also, we should always look to see what we already have across the company before we start creating a new capability. That is why our capability assessments are so important. Although we have established several integrations that can feed governance, the actual activities are not fully in place yet. We still need to improve our governance processes to ensure we are working on the right things going forward.”

“I am pretty well-versed on the IT4IT Standard,” says Terri, “And I actually participate in one of The Open Group IT4IT Forum work groups. So please, just let me know if you have any questions. If I don’t know the answer, I can probably find someone in the IT4IT Forum who does. I’m pretty well connected to many of the core members through the quarterly live events and through the virtual work group meetings I attend every month. Originally, I started going to the events to learn more about the TOGAF Standard. That’s where I stumbled across the IT4IT Standard. I’ve seen how well it works together with the TOGAF Standard.”

“Oh, that’s great, Terri,” says Kathleen, “I’m just learning about the breadth of the IT4IT Reference Architecture and the business value. The IT4IT Value Network has really helped us make our digital implementations cheaper, better, and faster. I’m still a novice, so thanks for letting me know about your network. I’ll definitely use you as a source of knowledge and expertise. The more I dig into the IT4IT Standard, the more I realize the strength of the framework for the governance of products and services. Now that our company is on its way to becoming digital and the business and technology are blending together when it comes to our strategy, I really believe we can use the IT4IT Standard to bring traceability from our company’s digital products from strategy through execution and into operations.”

Everyone nods in agreement and Terri finds herself smiling. She’s been trying for years to get the Enterprise Architecture team to use a consistent framework, like the IT4IT Reference Architecture, to manage products and services across the company. She was happy to see that others were realizing this, and it was finally happening. “You’ve got my support on using the IT4IT Reference Architecture for managing and governing our digital products and services,” she says. “Just let me know how I can help.”

“Well, I’ve not had time,” says Kathleen, “to devote to putting a new governance structure in place and I have been pondering who I would have confidence in to lead this important piece of our Digital Transformation. It would entail a big change from our current project-based governance to a more Agile digital product-based governance practice. Are you interested in taking the lead on creating a new governance function for managing architecture changes?”

“Sure, I would definitely like to take the lead,” says Terri. “It’s exactly the kind of challenge I’ve been preparing for. Thank you so much for the opportunity.”

Immediately after being given her assignment, Terri begins working on the Architecture Governance structure. She had already come across lots of material in The Open Group Library that she could use to help her shape the new governance function. Terri reminds herself that she will need a strong transition plan to lead the organization from project-based governance to an Agile, digital product-based governance structure.

Terri thinks through who the stakeholders would be for the new governance structure. Since they currently have both project-based and Agile/DevOps-based governance and are now moving to digital product-based governance, she needs to include all of the roles currently involved, such as project managers and Scrum masters. She comes up with a stakeholder list: Strategists, Architects, Business Relationship Managers, Portfolio Managers, Change Managers, Product Owners, Developers, and Operations. This covers all the roles that participate in the care and feeding of the product/service lifecycle. Another group Terri thinks would be important for representing the customer is the service center. She puts together a list of the names of representatives from each of the stakeholder groups that she thinks is needed to get this new governance structure up-and-running.

The toughest part about this effort, thinks Terri with some concern, is going to be getting agreement between the project-based people, who rally around regular gate reviews and excessive structure, and the intense Agile, MVP people, who like to try things out with very little structure in place. Both extremes have their valid points. We will need to go fast, she notes, with new technology, but it needs to be done with guardrails in place. So we will need to establish the minimum set of guardrails to both allow people the velocity they need, but also to keep them on track to safeguard the security, quality, customer satisfaction, and cost aspects of our digital solutions.

Terri quickly drafts a memo to the stakeholder representatives and their management, letting them know about the plan for a new governance structure and laying out a schedule. This effort will require leadership backing for the development of a new governance structure and its ongoing sustainment.

Thinking about all that has been done to date as part of the Digital Customer Intimacy strategic theme, Terri feels as though her team will be off to a good start on this new governance. The TOGAF and IT4IT Standard implementations are already in place, as is the automated pipeline for initiatives from Strategy to Operations, which includes the Architecture Repository and its connections to Development, Fulfillment, and Operations.

Referring back to the TOGAF Standard, Terri finds the section on Architecture Governance^[8] that clearly spells out the key elements for governance. She will need a cross-organizational Architecture Board, a comprehensive set of Architecture Principles, and an Architecture Compliance strategy with specific measures.

The TOGAF Standard also provides a list of catalogs that can be developed for governance and reference purposes.^[9] Value streams and business capabilities are at the top of the list. Pondering this, Terri comes to the conclusion that a catalog of value streams and business capabilities would be extremely helpful to ensure that architects have what they need to assess business capabilities against the company’s key value streams.

As Terri continues to pore through references that might help her to get a handle on the right amount of governance to impose in an Agile environment, she finds information in the DPBoK Standard^[10] that states: “The conflict between Agile methods and traditional approaches revolves around the transition from a single, collaborative team to a ‘team of teams’ requiring coordination, and the eventual institution of architecture and governance practices”.

This may be the kind of backup I will need, thinks Terri, to convince the “governance naysayers” that we will need just enough governance in place to coordinate standards and guidance across a team of teams. If we give staff the enablers they need, like building blocks, compliance checklists, catalogs, principles, and reference architectures, it will be much easier for them to comply to standards and guidelines. We’ll need to be sure our repository of information is easy to navigate and accessible to all staff, and we’ll also need to be sure to keep lines of communication concerning changes to procedure open to all of the teams and ensure clear expectations for adherence to policies. We need to make sure to prevent excessive gate reviews by having regular interactions with the teams to convey the vision and expected outcomes.

Terri leans back in her chair, tired of analyzing. She feels she is losing her creativity and starting to get blocked. Brutus her dog, sensing her change in focus, and ever the opportunist, decides to make her aware it must now be time for a walk. She smiles at Brutus, her loyal companion. She would have gone nuts without him, working from home for so long.

“Come on then!” says Terri, grabbing his leash. She picks Brutus up and they take the elevator down to start their normal stroll through the park. As usual when walking in the park, her mind starts to drift and, before she knows it, she realizes a lot has been done already in support of the two stream-aligned teams of the Digital Customer Intimacy initiative. She pauses, nodding her head as she goes through each of the changes that have already been implemented: we have embedded the architects into the stream-aligned teams and they are participating in the major ceremonies, such as sprint planning; and we also introduced ADRs as a practice to capture architecture decisions made in teams.

Brutus pulls at the leash, but Terri is deep in thought, planning to recommend that this practice is continued and rolled out to the wider organization. “Yes Brutus,” she says. “We can provide the teams with the support they need and give them the means to be able to take responsibility. We can probably get by with performing audits – for example, using retrospectives – when no other option is available.” Terri is smiling, but Brutus does not look impressed, especially when Terri ignores his attempts to make her speed up. “This shouldn’t be needed very often if we give guidance up-front to be sure policies and procedures are being followed. It will be much better than checking after the fact in gate reviews. Yes, it will Brutus! This should make us a lot more Agile.” Finally, she lets Brutus off his leash and throws his favorite ball.

When she is back from her walk, completely refreshed, she understands where the current challenge is. What we have implemented, she now realizes, provides the feedback loop that we need to manage the realization of the strategy and its architecture; however, defining the guidance is currently too much focused on the team level, not on the coordination across the teams, nor on the overall direction of the company.

Although her first reaction is to implement a Board to facilitate decision-making, she realizes it will create a gate with a queue and wait time, which is exactly what she wants to prevent. On the team level, she thinks, we have been able to use planning sessions and have embedded architecture into the work. Perhaps we can do something here as well.

Pausing for a moment, Terri notices that the team of teams concept from the DPBoK Standard [1] could very well be the place where coordination and guidance of architecture across the teams can be done. She concludes her notes by outlining the point she wants to make: by implementing the team of teams approach for each of the main value streams and embedding architecture into the ceremonies we can coordinate the collaboration across closely-related teams, but the enterprise level is something else.

Unfortunately, she is not able to quickly find a solution and decides, in frustration, to shut down her laptop, call it a night, and deal with it tomorrow.

The next morning, Terri is driving back to the office when it hits her. As an organization, she realizes, we have already implemented a QBR process. This has allowed the product owners to align the future of our products and services with the business and collect future demand, just like a typical sales organization does with its customers.

Smiling behind the wheel of her car, Terri decides to use this meeting to discuss the priorities, objectives, and results of each of the value streams. Each value stream can be represented by the lead from the team of teams setup. They can discuss this with the other stakeholders in an alignment meeting and we will ask ourselves a simple question: when we add everything up, does it enable the company to realize its strategic goals? [23].

In the office, she spends an hour finalizing her notes to outline the results of her investigation. All in all, she is happy with the conclusions: good guidelines, enablers, and guardrails in place will assure the quality, and having frequent, interactive communication of the standards and guidelines, as well as expectations, will be the key to successfully removing gates. Working together and communication are really two of the keys to being able to decentralize decision-making and empower teams. Adjusting the way we plan and coordinate across the autonomous teams provides us with the means to govern and direct the organization without ivory towers.

Because social distancing measures are still in place, Terri schedules a virtual meeting with all of the stakeholder groups. She is confident that she has selected the right stakeholders to help her get the new governance in place. Terri always likes coming to a stakeholder meeting with some ideas in hand to get conversations started, so she prepares a series of slides to frame the need for a new governance structure and what should be included at a minimum to keep work flowing in an Agile way and ensure the consideration of quality, security, and budget constraints.

To view Terri’s slides, see Bonus Section F.

Terri opts to hold the kickoff meeting for developing the Agile governance structure virtually since many of the stakeholders are geographically dispersed. She starts out with the “burning platform”^[11] she has put together in Figure 11.

Terri is pleasantly surprised when she is able to get agreement from all but two very staunch Agile supporters. The others all agree that there needs to be some oversight in place and that Enterprise Architecture seems to be the likely candidate for ensuring the traceability of work being done on products and services from Strategy to Operations and also for Disposition. Disposition has not been a focus previously for the company and that has led to a lot of legacy technology still in the environment that is not being used, which has created technical debt.

She starts to go through her slides, telling the stakeholder group that the pre-work she did is just to get some conversation going and she encourages feedback. The group likes the core principles and corresponding questions that would help teams ensure they will stay in line with them. A couple of people say that they would like to study them more to see if there are additional questions that should be added.

“That would be great!” says Terri. “I am also envisioning that whatever we start out with will evolve as we bring our work through this governance structure.”

The group is also in favor of developing the suggested catalogs and thinks these will be extremely helpful enablers for people as they begin to follow the governance standards and guidance.

Next, Terri brings up two slides on the Governance Operating Model. First is the Governance Charter and Membership and the other is the Governance Structure. For the most part, the team agrees with the Charter and the Membership she has outlined. There is a little bit of grumbling from the two Agile die-hards about avoiding too much regulation and protecting their DevOps team’s need to be self-governing.

“Yes,” replies Terri. “That’s exactly what we need. All teams must be self-governing using our principles to guide them and our standards for consistency, with traceability from Strategy all the way through to Disposition.”

“I keep hearing you say we need traceability,” one of the Agile DevOps guys challenges her, “but what the heck do you really mean by that?”

“Great question,” says Terri. “Let me give you an example. Remember last year when there was work being done on some great new augmented reality technology that could save cycle time and reduce travel because people who needed technical support on some of our digital platforms would be able to stay at their location instead of wasting time by having the expert fly to us? The augmented reality digital initiative actually started in our Advanced Technology group. They had been trying out the technology but did not have a solid use-case. There wasn’t anything on the strategy roadmap and nothing to tie it to a business strategic theme. The initial work that was done by the Advanced Technology group kind of died on the vine eventually. Until recently, when the pandemic hit. Now there are lots of use-cases because people are being encouraged not to travel by plane.”

Terri pauses, anticipating a challenge and continues when no one speaks. “None of the work that was done by the Advanced Technology group was captured anywhere, so we are starting over from scratch. We have been able to tie it into the Digital Workplace strategic theme which is linked to several value streams. The solution can now be employed for use-cases that were identified as digital opportunities in the value streams. Traceability comes in when we are able to confirm that the architecture is consistent with the design and the implemented solution and that there is an owner identified to sustain the service.” She pauses again. The faces on her computer screen are focused, listening. She begins to feel more hopeful.

“We have to ensure that all along the way the value identified in the value stream has been delivered as expected by the customer. We want to have traceability for all of our products and services across the company for a few reasons. When changes are required, we will have all of the necessary information to make an informed decision about which processes, roles, information, and tools will be impacted across a value stream. Having that traceability along the product/service lifecycle will make the impacts from changes more visible. Additionally, at every point in the product/service lifecycle we can validate that important policies, procedures, and guidance are being followed so our solutions are consistent and have the required security and quality. We actually automated where key information is being stored in our core systems last year, which will make this a lot easier to do than it would have been in the past. For example, this has made it easier to find information about products and services from the time they were an Idea to the time they were deployed to production.” Terri looks up from the screen and takes a breath.

“So,” she continues, fully in her stride now and feeling far more confident, “the desire is that we will not have to do gate reviews in the future. Teams will self-govern based on all of the guidance communicated to them. Enterprise Architecture will stay involved with development through Operations with design-level involvement and periodic audits.” She takes a deep breath and concludes, “We are here to help you be more Agile. We are not here to hinder you as may have been the case in previous governance structures that required stringent gate reviews.”

“Wow!” Both of the Agile DevOps guys speak in unison and stare at Terri in amazement.

“You mean,” says the one who had been speaking out against governance the most, “we are all going to work together in the future and the governance will be across the entire product/service lifecycle? Does that mean there won’t be any separation between the Architects, DevOps, Security, and Support?”

“Yep, that is the plan. We will enable the autonomy by creating cross-functional teams using the team backlogs we’ve already implemented. We will align the teams which work together on a value stream into an Agile Release Train (ART),^[12] each ART being fully responsible for the end-to-end value stream. We will be using Program Increment planning events to align the work between the teams. No more siloed organizational units. So, are you on board?” Terri challenges them gently.

They both respond with a resounding, “Yes!”

“OK then,” says Terri, with a smile. “Let’s move on to the next topic of discussion, which is the frequency of meetings. I would like to start with weekly meetings while we are getting the Architecture Repository built up with standards and guidance, including catalogs, building blocks, reference architectures, and checklists. Once we have everything in place it will just be a matter of keeping it current. Is that OK?”

Everyone agrees and Terri moves on to her final topic: Governance Structure (Figure 12). She points out the Governance Board at the top of the product/service lifecycle.

“I am envisioning that these would be the core members of the governance team using the QBR ceremony to drive the direction of the company, govern alignment, and give guidance across the whole organization. The extended team members at the bottom are contributors to the standards and guidelines and would attend meetings as needed, depending on the agenda.”

“OK everyone,” Terri says, clasping her hands in front of her. “That’s everything I have for today. Thank you for your feedback so far. Does anyone have anything to add?”

Sarah Condor, the Head of PMO speaks up. “I am extremely pleased with what I am seeing here. This has been needed for quite some time. Thanks so much for taking the lead and for all of the research you have done on governance. The best part about all of this is that we will be working together toward common goals and we can actually see how products and services flow through the lifecycle and what needs to be delivered from Strategy through Operations. You are absolutely right that by centralizing our information, change management will be so much easier, which will make us go faster. This is all good.”

Kathleen parked her car, glad she could get this close to the entrance. Normally, she’d have to walk because the parking lot fills up quickly. It’s pouring down with rain and she makes a mental note, now that the pandemic is under control and everyone is starting to return to normal life, to put her umbrella back in the car after working at home for months. It’s Friday night and earlier that day she had rushed out of the office to be home for the dinner party planned for her daughter’s birthday, but when she got home she realized she’d forgotten her purse, and tomorrow they would go shopping so she decided to go back and get it the same evening.

Her plan was to just go in, say hello to Bart Sanders from building security, get the purse, wish Bart a good night, leave, and be home in 30 minutes from now. She glances up at the building as she walks in and notices lights burning on the second floor, which is strange.

“Hey Bart, how are you doing tonight, everything quiet in the office?” Kathleen greets Bart in the lobby.

“Not too bad with me, thanks, but I have to say, tonight is busy. Normally, Friday night is peaceful and I’m spending most of it alone, but this weekend a number of the Finance team are up there on the second floor. Working late on Friday night doesn’t happen a lot, so there must be something wrong. Are you here to help them as well?”

“No, I just came over to pick up my purse I had forgotten. You mean it’s the Finance team up there on the second floor?”

“Exactly. They’ve not left the office. They just ordered pizza and kept going. Does seem something is wrong – nobody would stay on a Friday night just for the fun of it.”

Actually, Kathleen and her team had been able to reduce the overtime dramatically lately. The new way of working was becoming the norm; the organization was more responsive to changes than ever, the new digital products were a success and gaining traction on the market, and the last time she worked late was because of the Hackathon they had organized.

“See you in a minute.” Kathleen steps into the elevator.

Against her better judgment, she decides to stop at the second floor on her way down. She can never resist a challenge and she wants to know what’s going on. When she enters the finance area, she sees all the finance leads of the different Business Units sitting in the large conference room, talking in small groups. She recognizes listing numbers on the whiteboards positioned around the room.

“Hey Kathleen. I did not expect to see you at this hour, what are you doing here?”

Startled, Kathleen spins around to find Fiona Hoekstra, the company CFO looking at her expectantly.

“Oh! Hi Fiona, I didn’t see you there! I had to swing back to the office because I forgot my purse. But I could ask you the same thing as I didn’t expect all of you to be here. Bart told me people in Finance are still working, and according to him, given the hour, it must be important. I thought I’d say hello and see if I can help?”

“It is important,” says Fiona, looking a little grim. “I’m not sure if you can help, but if you agree that what I’m about to tell you won’t leave this room, then I’ll fill you in.”

Fiona explains that she and Brad will be meeting with the Board of Directors in a special meeting by the end of next week to discuss the future of the company. One of the Board members had heard there is an activist shareholder trying to form a consortium to gain enough voting power to force a decision on breaking up the company. The Board member has started to form a counter strategy, which was to find a friendly buyer, and is asking his fellow Board members to agree to start scanning the market to allow them to be prepared at the next shareholder meeting.

Brad, however, had pushed back hard. His argument being that revenue was increasing now that the digital products were picking up. The Board was positive on the turnaround, but needed to understand the contribution of each of the digital products and the profitability of the Business Units. They had not forgotten the investments made following the merger, and the failure of the initial program. For them, a perfect way out would be to sell the company, leaving the shareholders with a nice return. On the other hand, if the profit of the combined products was showing a good enough return and all Business Units show future profits, they would be on the forefront of fighting the battle to prevent a break-up or sell-off, but for this they needed more information. Fiona had been given a week to come up with the numbers.

Fiona and her team had spent most of Friday collecting all the necessary information to have all the details ready for the Monday morning management team meeting. All costs had been collected and allocated to the various parts of the company. They had spent time incorporating the allocation of cost to the digital products and, except for the technology cost, they had managed the allocation. They had collected all the technology costs they were aware of, like the personnel cost, the cost of the data centers and infrastructure, and the bills of the various service providers. That part was relatively easy, but the distribution of the cost was not. In the past they had always used a key to distribute a lump sum of the total technology cost to all the Business Units as part of the corporate cost. They had been using various keys, such as the number of employees, or the total revenue. But whatever key they had used, it always led to big discussions in the management team, with some of the Business Unit leaders arguing they had to pay more than their fair share. With the increase in technology cost as part of the digitalization program, there is likely to be more discussions and, unfortunately, there won’t be the time to do it right.

“I think Brad and I will need to force a decision and then deal with the consequences. My team is exhausted, so unless you have something that can help us within the next 15 minutes, I’m calling it a night and we’ll use the same key as last year.”

Kathleen’s mind is racing. By now she is very familiar with the IT4IT Standard and knows that Finance is covered as one of the supporting functions within the digital Value Network. She had never given it much thought but given the problem just described by Fiona, she was going through a mental checklist.

“What if I tell you we have been tracking the usage ourselves over the past months? I mean not by cost, but by using more and more automation, we are now able to track usage. We have been investing in a Configuration Management Database (CMDB) that is centered around the products and offerings we are providing to the market. For example, people are now working in stream-aligned teams, focused on the products we provide, not just a project, but for the whole lifecycle. This means we know which products each team is supporting. We have started to provide an automated catalog system to order infrastructure, which means everything is ordered in relation to a product. And we have rearranged the infrastructure services of internal and external service providers to show how their services are supporting the different products, which means there is a link from the infrastructure services to the products. We’ve been doing this to be able to improve efficiency, understand where things are not working as expected, and to identify the impact changes and incidents have on the products we as a company provide to our customers. It’s helped us to make a shift from projects to products. I wonder if this is actually something that can help you in this case, too? I mean we might still have to use distribution keys, but probably in much less of a lump-sum way.”

Fiona starts to smile. “I wish you had stepped in earlier. We don’t have time to detail all of this out in the next hour, but let’s take one example and work that out, so I can provide an alternative to the distribution key. If the management team agrees, we can then take the rest of the week to finalize cost distribution.”

After Kathleen has texted Sven to say she will be late, and Sven has responded by asking which part of the world is coming to an end that it needs to be done on a Friday night, she sits down with the Finance team and, using the information in the CMDB and the connected systems, they work out an example of distributing the cost to the different digital products, validating that the approach is sound.

At the end, Fiona feels comfortable enough to bring the result to the management team and arranges to contact Kathleen after Monday’s meeting to plan the next step.

The next Monday, Fiona walks into Kathleen’s office. “You know, this was the first time I have been able to get approval of all Business Unit leaders to accept the allocation of cost, and we have the approval to work out the rest as well.”

“That’s great Fiona. I am happy our investment in the IT4IT Standard is paying off on this front as well.”

“If I knew what you are talking about, I might agree,” says Fiona shaking her head. “However, I never understand this ‘tech-speak’. It just makes it complicated for me. I just want to track costs and assets so I can better manage the budget and recommend good investment decisions.”

“Exactly!” Kathleen replies, excited. “And I agree. It’s not the name of the standard that’s important, it’s what it does for us and for you. It has given us a framework and guidance we can use in solving our business challenges. Actually, let me show you something. The things you care about tracking like cost, budget, and assets are all embedded in this framework.”

Kathleen shows Fiona the four IT4IT value streams, highlighting the different elements mentioned. “We have been implementing the systems we internally use according to this framework, and although we did not do this to support the Finance department, it did show its value on Friday didn’t it?”

“So, you mean we could get all of this out of your IT4IT system?”

“Not really,” says Kathleen. “The IT4IT Standard itself is not a system or an application. It’s a reference architecture that helps us understand how we can best combine the different systems we use to support the needs of the business. We’ve used it as guidance to implement and integrate the parts we need to support our product operations. But! With a small investment to create an integration with your financial systems, we could, for example, create a proper asset management system. Would that be helpful?”

“Yes. But let’s leave that for later. Right now, I need your help preparing the rest of the cost allocations to be ready for this Board meeting.”

Throughout the rest of the week, Kathleen helps Fiona’s team with the cost allocation and late Friday night she gets a text message: “The Board is on board!”

In the following weeks, Kathleen works with one of the Finance leads to identify the information needs of the Finance team and where that information could be found within the existing systems. Together they create the investment Idea. Once that is approved, they create the necessary Backlog Items. A couple of weeks later, the first integrations come online and before long the setup is fine-tuned.

Three months later, Kathleen decides to join the shareholder meeting for the first time in her career. She owns a small number of shares, so she gets into the meeting and sits in the back. The tension is high and the activist shareholders do try to bring to a vote a proposal to break up the company, but Brad, Fiona, and the Chairman of the Board manage to convince the majority of shareholders that the best strategy is to continue on the path ArchiSurance has chosen. On her way out, Kathleen feels happy that she had not given up when she had that meeting with Dick. He was near to being out of a job, but as a team they have been able to turn it around.

“It is all your fault,” screams Hans Pickle as he walks into the room where Kathleen is working. “Because of your work, the go-live of the Prolongation Application replacement failed and we had to do a roll back.”

Kathleen looks up from her work to sees Hans, fuming and pointing frantically to a stack of papers in his other hand as if Kathleen was privy to what was on them.

“Oh don’t play dumb with me,” he continues, when Kathleen says nothing. “It’s all here in this post mortem report we had to do for the failed go-live. Because of your work, all kinds of new requirements are now added to the replacement, making it even more difficult to replace. Thank you very much! This is going to cost the organization time and money and I’m on my way to Brad to make it very clear exactly who’s to blame for this issue.” Hans turns and storms out of the room.

Kathleen has to stop herself from chasing after Hans. He always blames others and never wants to listen to any advice. In the CAB, where the release of the B.L.O.S. replacement was discussed, she had advised against it, indicating that the testing was not conclusive on the ability to provide all external systems with the information they need. She got into a heated debate with him, but, in the end, Hans had put all his weight behind the change and forced an approval, threatening anyone who stood in his way. Now, the only thing she wants to say to Hans is: “I told you so”. But, given the connections Hans has in the organization, she is not feeling very at ease.

Two hours later, she gets a request from Brad to come to his office and with her stomach churning she walks over.

As she enters the room, Brad, Dick, and Amy stop their conversation. Brad waves an outstretched hand to indicate an empty chair. “Hi Kathleen, thanks for joining us at such a short notice. Please take a seat. Recently, I have been following this B.L.O.S. replacement and, frankly, I am not happy with the current progress.”

“I am really sorry,” says Kathleen, looking at Dick and Amy for help. “But everything I did was to help the business to make sure they got what they needed.”

“Yes, yes, I know,” Brad cuts her off. “And that is exactly why I wanted to talk to you. Dick, Amy, and I have been talking about this and we have come to the conclusion that Hans’ approach is not what we need. Apparently, he has been blocking development of the digital products we need for our survival and, as I understand, your approach to find ways to help the business has been the right one. I do not know all the details of how this works, but I would like it if you can find a way to create an architecture to help us get rid of B.L.O.S.”

“Uh, yes,” replies Kathleen, her mind racing. “I think that is possible.”

Before she can continue, Brad replies, “That is fantastic, thank you so much. I am sure you will be able to do this, certainly after all the work you have done in architecting the way we operate as a company. I suggest you and Dick work out the details and report back to me next week.”

“For sure,” says Dick. “We will make an appointment with you to discuss the plan.”

Brad thanks them for their ongoing support, Dick and Amy start standing up, getting ready to leave. Kathleen gets the hint and follows their example. The three of them walk out of Brad’s office.

“What just happened? Where is Hans? Does the team know about this? Where …​? I do not know where to start!” says Kathleen.

“That’s a lot of questions! One: You got the assignment to re-architect the B.L.O.S. application. Two: I think Hans has come to the conclusion his skills are better suited on a different project. Three: No, the team does not know, but I think they would welcome the change. Four: I guess you can figure this out in the coming days,” replies Dick. “I am really sorry, but I’m running late. Please come by my office later today so we can discuss the details.” And off he goes leaving Kathleen, as usual, with more questions than answers.

“Let’s get a coffee,” says Amy, and they venture in the direction of the coffee corner. “And I guess this is a goodbye from me as well. Today’s my last day working here as an Agile coach. The last thing I think you should know is that since we met, I have been working with Brad on how his organization had to change. He noticed the change that began with the merger slowing down. He hired my company to help him with a restart and we decided to do this from within, so I became a consultant to help the organization make the change, and not just to coach the leadership.”

Now it starts to become clear to Kathleen. All this time it was Amy who had been keeping Brad aware of her plans and arranging encounters. Now it made sense why she was in the room with Brad and Dick this afternoon. As they drink their coffee, they discuss the various changes that have been made since they met, and they conclude that the organization is improving more and more. At the end they say their farewells with a promise to stay in touch.

As Kathleen tries to leave the office, a call comes in. She hesitates as she doesn’t recognize the number, but then reluctantly answers it.

At that hour of the evening in the US, she is surprised to hear a man with a British accent on the other end of the phone. It is none other than Steve Nunn, President and CEO of The Open Group. Kathleen had met him at a conference she had attended about a year ago. At the time, Steve had seemed very interested in the fact that ArchiSurance was using several of The Open Group standards together to help in its Digital Transformation.

After a few pleasantries, Steve got right to the point. “Kathleen, I’m calling to see how things are going with your Digital Transformation at ArchiSurance. But the real reason for my call is to personally invite you to be a plenary speaker at our upcoming event. Would you be interested and available to accept?”

Kathleen is flattered. “Thank you, Steve. I accept!”

“Great, I’m so glad you will join us! Thank you. I know our event attendees will be very interested in your case study and the outcomes you have achieved from using The Open Group standards together. You may not know it, but part of the charter for our events is to provide opportunities for members and the public to learn from the experience of other members. As you’ve already experienced, at all our events we host formal presentations in our plenary and track sessions, plus informal networking opportunities over meals and happy hours to facilitate learning through personal connections. I hope you can stay after your presentation is over and participate in all of it.”

“Yes, OK Steve, I will plan on that. And – to answer your other question from earlier – our Digital Transformation is going really well. In fact, you’ll be happy to hear that I would attribute a large portion of that success to our decision to use The Open Group standards.”

“That’s wonderful to hear, Kathleen!”

“Actually, Steve, this might be a good opportunity for me to ask you for something.”

“At your service. How can I help?”

“Well, there are several members and staff at The Open Group that I’d like to meet and thank personally for their contributions to our success. Would you help me to get in touch with them?”

“Of course, I’d be pleased to make introductions for you! Who in particular would you like to meet?”

“Well, we’ve been really helped in our transformation work by several of The Open Group publications. So, it would be great to meet some of your member authors. For example, we read The Open Group Guide to Tool Rationalization using the IT4IT Reference Architecture Standard [26] and followed its clear step-by-step “how to” guidance to rationalize our own toolset here at ArchiSurance. That document saved us so much time and money that we were then able to free up budget for use on more strategic initiatives. We also used concepts from another IT4IT Forum White Paper called Why Business and IT Must Co-Create Strategy for a Digital Enterprise [27]. We adopted the vision in that paper which led us to mature our targets for our “to be” state. That’s part of what helped us leapfrog ahead in how we construct and execute our strategy for digital products today.”

“Oh sure, I’d be happy to introduce you, Kathleen. Many of those authors are our most active contributors and they attend several of our quarterly events every year. It shouldn’t be too hard for me to track them down.”

“Thank you, Steve. And I’d also like to meet the leaders of the IT4IT Forum and the Architecture Forum; a couple of members of my team have been actively participating in Forum work groups that are driving the next versions of your architecture-based standards.”

“Oh, that goes without saying. Did you know that all our Forums are led by members like you who are elected as Forum officers by their member peers? Even without my help, once you’re at our event, you’ll find that our staff Forum Directors and our Member Chairs always reach out proactively to welcome new participants.”

“Well, that’s great because I’d also love to meet the authors and leaders of another one of your standards: the DPBoK Standard was timely for us because it became our handbook for Digital Transformation. It kept us on track with the really important part: our people and investing in their skills development.”

“Oh, I’m so glad you took advantage of the fact that we have ongoing special projects like the DPBoK Standard. That’s an example of one of our cross-Forum projects which we open to all members to both learn from and contribute to, with real-world, pragmatic experience. They’ll be pleased to meet you in person.”

“I really do need to go; a family dinner awaits. But if I could share just one last thought with you? Here at ArchiSurance, we keep finding more and more ways to participate and gain benefits for our whole division by being more active in The Open Group Forums. The more we’ve investigated and got involved, the bigger our return has been. Now, we are one of the companies helping to determine the direction of the next versions of a few of your standards. So, at this point, I guess you might call us a “key influencer” – we’ve hit the big time, ha ha!”

“Well, it’s great to hear about your journey so far with the Forum, Kathleen. I’ll look forward to seeing you on our plenary stage next quarter and until then, enjoy that journey – and your dinner, too! Cheers! And bye for now.”

Kathleen smiles, hangs up the phone. She grabs her keys and laptop bag, and heads out the door. On the drive home she thinks more about her journey with The Open Group.

She had originally found out about The Open Group when the Strategy and Architecture group started using the TOGAF Standard. ArchiSurance became a member of The Open Group when a group of architects was going through TOGAF Training and Certification. Subsequently, she found out about the IT4IT Standard and simply downloaded it for free from The Open Group website. After a cursory read, she had realized how much it could help accelerate the team in their solutioning for current initiatives and challenges. It was such a small start, she mused, but look at what a positive impact becoming members has had on our organization.

She thought about all the professional growth her own peers like Terri had experienced as a result of their growing engagement in the Forum. Several had gone from just joining and listening to Forum work group virtual sessions, to later becoming work group leaders and even proposing hot topics and launching their own Forum work groups. Even better, several of her colleagues were now primary authors on thought leadership and “how to” publications for the industry, or elected officers of one of the Forums, which then led to speaking engagements and video recordings at the live events.

As she pulls into the driveway after a long but satisfying day at work, Kathleen remembers back to when ArchiSurance had cast their “one vote per organization” in their first Forum “ballot” as new members of The Open Group. She contrasts that to last month when she and her colleagues had watched the work group come to consensus on accepting the final version of an entire chapter of the standard that her team had drafted and submitted for review for the next version. The next time ArchiSurance cast their ballot, it will be to vote in the Company Review for a standard they had helped to write. What a great thing to be able to say!

We helped to build an industry open standard, she thinks, that is available free for anyone to use to improve their digital product delivery. That’s pretty darn cool. The car door clicks shut behind her and she walks toward the warm glow of the porch light and her family waiting for her inside.

Several months later, Kathleen approaches the registration desk of The Open Group event. She introduces herself as a plenary speaker and asks to be connected to Steve Nunn. Taking the time to enjoy breakfast and a cup of coffee, she is pleased at how friendly the other registered attendees are as a few of them walk up and introduce themselves and engage her in conversation near the coffee station. By the time she is ready to enter the plenary ballroom, she has a sense of camaraderie and feels less nervous about who might be in the audience and whether her presentation topic will be of interest to them.

Shortly, Steve Nunn calls Kathleen to the stage. “And now I have a special treat for you,” he addresses the audience. “Many of you tell me that you like our Case Study presentations best. You know, the ones delivered by people who don’t just talk the talk but have also had to walk the walk – sometimes walking across fire?”

The audience laughs, based on shared experience.

“And many of you have also shared with me that Digital Transformation and digital product delivery is what is most on the minds of your organization’s leaders this year. Well, Dr. Kathleen Stone, Chief Architect with ArchiSurance, is going to give you the story of their Digital Transformation. I was so impressed by all that the company ArchiSurance has accomplished, that I invited Dr. Stone here to share with you her real-world story of how they kicked off a Digital Customer Intimacy initiative a little over a year ago. She’ll share a bit about the how, and then what outcomes they have achieved so far. And, finally, in a topic near and dear to my own heart, she will also share with you how The Open Group portfolio of open digital standards helped strengthen and accelerate their Digital Transformation.”

Stretching out his arm toward Kathleen, Steve says, “So now, would you please give a big warm welcome from The Open Group to Kathleen.”

As the applause dies down, Kathleen walks out from behind the podium, and stands in the middle of the stage to begin her presentation to The Open Group. She directly addresses the whole audience using the same “Imagine” slide she used in her ArchiSurance kickoff meeting to her own leadership. This sets the scene as she begins to tell the story of the Digital Transformation journey ArchiSurance has been on for over a year.

“We’d just been through a merger of three companies into one. After all the streamlining of processes and the rationalization of systems that was done during the merger, we felt we’d made some good strides toward becoming an Agile organization. However, analysis showed we hadn’t really gone beyond the implementation of Agile in development, or as Amy Lee, the external consultant we hired indicated, we only implemented Agile ceremonies! It wasn’t really Dev and Ops, let alone being transformed to a Digital Organization! In fact, instead of being Agile, we started to lose a grip on the budget. So, being honest with ourselves, we recognized we hadn’t changed much more than the introduction of scrumming as a way to develop software, and we had kept everything else pretty much the same as before. It was time to transform the whole organization, and get our core operational value streams in order, with cross-functional teams that work together.”

Kathleen steps back and turns slightly to look up at the screen. “I will never forget this town hall meeting, I really felt we were turning the company around. I had the honor to present our ideas to get everybody on board. I knew I still had to convince some who were cynical about change. And others who thought they might lose the empires they had built! I got on the stage and asked everyone to close their eyes, to imagine …​” She pauses, and takes a moment to look at the audience.

"Well," she smiles, feeling a real sense of pride. "We don’t have to imagine anymore. At ArchiSurance, we are a digital enterprise. Our organizational structure consists of teams of teams that work across key operational value streams with everyone working on common goals and outcomes. Our budgets are aligned to the value streams, helping us to make good investment choices holistically instead of in our functional silos. In fact, our silos have been broken down so much that redundancy and duplication in our environments is almost non-existent. We are Agile in our digital product development, from Ideation and Strategy, through Development and Operations. Best of all is that our customers are happy. We no longer get the complaints about being transferred from department to department that we used to get. Now we hear from our customers that they are happy with our service and they get an immediate response and help. We also have the people, processes, and technology in place for continuous shared customer insights. In other words we are in touch and in tune with our customers. We did this by using an outside-in approach, with our customer being the key stakeholder.”

Kathleen moves on to Figure 13. “As you can see, we really owe a large part of our success to The Open Group standards,” she says enthusiastically. “The TOGAF Standard was used as our architecture method for determining the work to be done. The IT4IT Standard was used to enhance the flow of the work and it ensured the capture of service and product lifecycle deliverables. We used the ArchiMate Standard for modeling the Architecture Vision and the Business, Information Systems, and Technology Architectures. These open digital standards really gave us a map for our digital journey.” She turns back to the audience.

“We used the IT4IT Standard to guide us through the data flow automation of our deliverables. In our baseline state we had lots of disparate systems for keeping track of our architecture, initiatives, development, and service management deliverables. There was also a lack of communication between groups because the systems were built independently of each other. We were able to narrow the core systems down to four, and build integrations between each so that the information would flow from one system to the next. This eliminated lots of manual re-entry of data and reduced the cycle time of getting an Idea approved through funding down to a few days instead of taking up to six weeks, like it used to. This next slide (Figure 14) shows the data objects stored in each of the four systems. The data objects for the Digital Product Backbone are the thread that creates traceability from the portfolio to Operations. We hope to eventually have one centralized system, but for now the integrations are working well.”

Beginning to shake off the jitters from being on the main stage, Kathleen carries on with more ease. “I would like to walk you through some of the key deliverables on this next slide (Figure 15). I cannot say enough about the work our Business Architects did to frame what we needed to do. As I mentioned before, we used The Open Group TOGAF Standard [19] to guide us, as well as the extremely helpful TOGAF^® Series Guides. The Business Architects spent several weeks interviewing different types of stakeholder groups, gathering the pain points, concerns, ambitions, and dreams related to the current situation and understanding of their vision and objectives. The information obtained was used to characterize the baseline state and to create a capability heat map to ascertain our gaps with the target state. All of this was done in the context of an end-to-end value stream. The gaps led to opportunities and solutions that were prioritized, and, from that, we created our roadmap.

The result is four big accomplishments:

All together, these changes have helped to make us a digital company.”

Kathleen pauses again to look at the audience. She smiles. “As I said at the beginning of my presentation, we owe a good measure of our success to The Open Group standards. They provided us with a map for our digital journey. Here, on my next slide (Figure 16), is a list of the successes and lessons learned.”

Kathleen gives the audience a few moments to read the slide. “The one thing I will mention here,” she says, “is that the biggest lesson was that there is an enormous amount of work that needs to be done in most organizations to become a digital enterprise and most of that work has nothing to do with technology. People and lines of communication are equally as important as the technology. Value streams and working end-to-end with cross-functional teams has been one of the keys to our success. I want to share our Digital Customer Intimacy roadmap with you, Figure 17. It really shows the journey. We color-coded it so you can clearly see where we used the TOGAF Standard (in yellow) and the IT4IT Standard (in blue).” Kathleen pauses again to let the audience take in the details.

“We started strategic planning with the business in Q4 of last year. It was the first time IT had a seat at the table with the business. Previously IT developed their strategy, and the business developed theirs, and then there would be an attempt to align them. The strategy discussions together were so successful that IT kept being invited back and now it is second nature for IT and the business to work together. The best part about co-creating the strategy as a regular cadence is that the work outlined during strategy sessions automatically gets carried forward into DevSecOps because they have a seat. Also, when it is time to deploy solutions, the Operations group is ready because they have been involved in the strategy sessions and know what is coming down the pike.”

Kathleen looks up at the screen again. “So, you can see on the roadmap that the development of a governance structure was started early in the schedule. This was due to the agility we wanted to achieve with digital product development. We needed to have principles and guardrails established to keep us on track so the ingrained gating processes did not bog us down. If we were going to eliminate the restrictive gates, we needed to put forth new, more flexible guidelines.” Kathleen reached for the glass of water on the podium and took a quick sip.

“The TOGAF Standard gave us the methods for developing Architecture Runways very quickly for our build iterations and we established many building blocks and reference architectures that will help us with ongoing initiatives. The Business Architecture work that was done helped shape the vision and strategy for the development teams and only required minor modifications throughout build iterations. Governance and change management methods were firmed up early and modifications were made as needed during each iteration. We were also able to implement new guidelines for the architects that made it permissible for them to deliver only the level of granularity needed for each build iteration to speed up the development of Architecture Runways. We were steered by a reference from The Open Group that helps guide the core architecture needed for each iteration.” ^[13]

Kathleen is reassured to see that several members of the audience are nodding and one or two are even taking notes. She continues. “The IT4IT Standard for digital really helped us to build our product development tool chain. For example, the Strategy to Portfolio value stream laid out for us the data linkages required to achieve full traceability from a strategic theme to Enterprise Architecture, which forms the set of proposals that turn into Portfolio Backlog and Product Backlog. The same was achieved for Requirement to Deploy, Request to Fulfill, and Detect to Correct value streams, giving full traceability of the product lifecycle by integrating our primary tracking tools.”

She clicked to reveal the next slide. “Figure 18 shows the way we used the TOGAF ADM in the past, where we would create all of the artifacts before starting any of the development work. With Agile and the need to build in increments to add value iteratively, we have adjusted to only build enough Architecture Runway for each MVP. This approach adds value with each release of a product and promotes continuous improvement.”

Kathleen clicked again. “Figure 19 shows the core architecture we developed for each iteration in more detail and how the level of completion increases as the shade becomes darker. For example, in the first iteration, the future vision is the most important element to establish with stakeholders. It becomes the guiding light for all of the teams. Business Architecture is shaded a bit lighter and it also needs to be started early to establish the baseline state. The Business Architecture will continue to be refined in future iterations as gaps are uncovered in getting to the target state defined by the vision. Requirements and governance are lighter than the Business Architecture in the early iterations, and need to be started early as well, but may not be as well formulated until after development begins and an MVP release or two have been completed. The DPBoK Standard endorses this style of incremental architecture, stating that “large system changes are inherently risky, and any intervention into a complex system is better undertaken as a series of smaller, incremental changes, with frequent monitoring and assessment” [1].”

Kathleen draws a deep breath and begins to bring her presentation to a close.

“Well, that was our Digital Transformation journey to date. As I have described, not only did we deploy digital capabilities, but we also changed our culture and way of working from silos to team structures across value streams. When we did that, we had to change the way money was being allocated to the functional groups to a shared value stream funding model. Another big change was to disband our traditional project methodology and gating to get to a continuous product lifecycle model. All these transformations make us Agile and provide the velocity to take on digital product implementations as a way of doing business. The biggest lift was getting our business working together on the most important objectives and the traceability of work products from Strategy to Operations.”

As Kathleen finishes, Steve comes back up to the stage and invites her to take a seat. “Great, thank you. Quite a journey! And congratulations on where you’ve got to. We have some great questions from the audience for you. The first question: how did you get your leadership team to buy into organizing teams across value streams?”

“Well, that was one of the more difficult culture changes we made because we wanted to break down the political barriers between the functional groups, but did not want to completely tear them down. The functional groups are the pillars that hold up the structure of our organization by maintaining the policies and procedures for a specific area, and the value streams run across them. Most of the silo thinking and barriers were due to established goal structures. Each functional group was responsible for completing their own goals within their own budget, which inhibited working together toward common outcomes. Simultaneously, this suppressed cross-functional thinking because functional silos were only accountable for their piece of the product, which created a bottleneck effect; work stuck in queues waiting for each functional group to pass it along to the next. This silo way of thinking also resulted in many duplicate tools being developed to store the same type of product lifecycle information. It took quite a while to get leadership to see the value of working in teams with a shared funding model^[14] across value streams toward common goals, but it has been tried and proven now with several of our value stream team implementations. We do it one value stream at a time and the benefits speak for themselves as the flow of work increases when teams have the same outcomes they are working to achieve. We also set up an accountability framework where people are rewarded for working together versus the silo way of working where people were rewarded for staying within their own boundaries and scope.”

“Thanks, Kathleen,” says Steve, “for answering that especially important question concerning Digital Transformation. I don’t think we can say enough about the importance of teaming across value streams to work on common outcomes, which inevitably increases the visibility and flow of work. Thank you. Let me move on to the next question. I believe you had to deal with an issue caused by unexpected changes in the system? Tell us about that.”

“Yes, we had issues with the operation of the new digital products platform. Our customers began to experience problems accessing their own information, and new requests just weren’t making it through. To make it worse, the Operations team could not get anything out of their monitoring systems, so they were logging in manually to individual servers without access to any centralized information. I was away on holiday – just about to go through airport security – and my colleague, Nick, had set up two incident resolution swarms, one for the product issue and one for the monitoring issue. He rang me just as I was at the airport. We quickly went through all deployments done by the teams in the previous 48 hours, and started to look for changes that must have taken place outside the automated approach. Then it hit us! The Security team had recently released a new version of their security platform. This new system had its own AI functionality and automatically began to apply the highest level of security to identified mission-critical systems, including any new monitoring systems – which the Enterprise Architecture team had not been aware of. So, we contacted the Security team and brought them into the incident swarm. The problem was soon solved. And after the incident we looked at the IT4IT value streams again. It seemed that the “Detect to Correct” value stream would help us to understand the current state of production, to enable a comparison between the Actual Product Instance and the Desired Product Instance to allow the discovery of something implemented outside the approval process, and also identify the potential impact of changes, by making sure that a register of all changes is maintained in a central repository. We can now track transition states and assess the target state, which gives us much better visibility into the Architecture Change Management.”

“Thanks, Kathleen. So, you’ve clearly got everything set up going forward, but as with any company out there, you must have been using those monolithic systems which are too big to change and at the same time create a blocker for transformation. How did you solve the issue of these monolithic and often legacy systems?”

“Oh, no, not the B.L.O.S.!” Kathleen groans. “Oh, sorry Steve. I mean the Prolongation Application! The B.L.O.S. was not its official name – but that’s what it became known as: the Big Ludicrous Old System! This was a system marked for replacement for many years because it became more and more of a liability. It simply was not possible to scale any further. Unfortunately, we just failed at every attempt of replacement! It became a collective headache for us all. Every time the team tried to deliver a replacement system, the test cycle found something else the current system was doing that nobody could have predicted. And it seemed that everybody needed to wait on this replacement system, but everyone could see it was not happening. Poor old Hans Pickle! He had the task of replacing this legacy system. It was connected to so many processes it was just too big to fail. Every attempt to dismantle the application failed to deliver. It just became a liability. Our consultant, Amy Lee, asked whether our big-bang approach, to replace it all at once, was really the best way to go to. But we couldn’t see any other option. As Ben – Ben Cohan, one of our Business Analysts – pointed out, all the data he needed was available in the application – it was just all over the place! There was no API in place to extract data using a query. I realized that regulations had forced a backup of data to be created for all critical systems, for business continuity. So, it was just a case of checking with the Risk Management team to see if that data contained the information Ben needed, creating a quick fix. This fix allowed us to develop solutions for other integrations as well, removing the strain on the B.L.O.S.”

“But,” says Steve, “That did not solve the real problem of replacing the B.L.O.S.?”

“No. As Amy pointed out, it’s not always possible, or even the best approach, to try to replace something that big using a big-bang. So, we did our research and found a concept called “strangler pattern” referenced in the O-AA Standard. It basically means that sometimes you have to create room to breathe by slowly strangling something. It allowed us to create space to evolve a replacement behind an API, while bypassing the B.L.O.S. and keeping the data in sync.”

“Well, that sounds like a good result for such an issue. We have time for one more question: if you had anything you would do over or better, what would it be?”

Kathleen responds very quickly. “Getting Architecture Runways in place faster is something I would focus on more. I did not really realize how much the architects and strategists need to work with the Business Relationship, Portfolio, and DevSecOps teams to keep all the work products in sync continuously in our Agile world. I did not recognize that the architects needed to be at every team synchronization meeting until it was almost too late. They need to be involved to keep the teams in line with architecture quality attributes, principles, and standards. Strategists, Business Relationship Managers, and Portfolio Managers needed to be there too, so we could adjust as needed and stay in sync with the business. Strategy is no longer a once every three-to-five-year conversation. The discussion needs to be continuous.”

“Thanks so much for being here today, Kathleen. It means a lot to us here at The Open Group to hear about real successes at our members’ companies using the standards that have been developed by the consortium. Also, thank you Kathleen for your company’s contributions to the TOGAF and IT4IT Standards.” Steve turns to the audience. “We will see you all back here in the auditorium after a 15-minute coffee break.” The audience claps for several moments and then begins to wander into the hall for the break. Several members come up to Kathleen to share their own experiences and ask additional questions.

At the end of the conference Kathleen leaves feeling accomplished, not only with her internal work at ArchiSurance toward a successful Digital Transformation, but also for the external work her team had contributed to the architecture discipline through The Open Group.

Minutes: Architecture Team Meeting

Date: July 1

Present: Kathleen Stone (KS), Tony Gonzales (TG), Nick Ross (NR), Terri Nichols (TN), Rakesh Gupta (RG), Greg Morrison (GM), Philip Potter (PP)

KS outlines the plan to identify stakeholders in order to start conducting interviews.

NR facilitates the meeting to compose draft lists:

TN asks where all of the information to be collected and the artifacts built will be stored to enable stakeholder access from across all of the functional groups.

TN points out it might make sense to have a common repository for documents with multiple functional groups being involved to avoid fragmentation of the documentation in each functional group’s own document collaboration site.

TN suggests that maybe it could even be organized by the product lifecycle?

ACTION: KS will come back with an answer on this very soon.

KS presents the next steps and logistics – to get the interviews scheduled and start gathering pain points and concerns from our stakeholders.

ACTION: TG to develop the schedule and book conference rooms.

KS outlines the plan:

KS points out that a rough draft of the groupings will be drawn up but not finalized until a better understanding of the dependencies is available.

KS adds that the Stakeholder Map is very important to get right because it is what will be used to begin shaping the Architecture Vision and the Business Architecture.

ACTION: NR to take the leadership of completing the Architecture Vision to include the Stakeholder Map, Motivation diagrams, and the value stream capability assessments.

Deadline: KS sets a target of two weeks to complete this effort.

Meeting: Architecture Team

Date: August 13, 8.00am

Present: Kathleen Stone (KS), Tony Gonzales (TG), Nick Ross (NR), Terri Nichols (TN), Rakesh Gupta (RG), Greg Morrison (GM), Philip Potter (PP)

KS welcomes and thanks everyone in recognition of the early scheduling of this meeting.

KS thanks NR for his efforts along with the other Business Architects (TN, RG, GM, and PP) in conducting the stakeholder meetings and completing the Stakeholder Map, with their concerns and the planned artifacts for each stakeholder, as well as creating the Motivation diagrams and solution concepts based on the feedback from the stakeholder meetings.

KS points out that while NR had initially requested to meet with her and the Business Architects to review progress and look at next steps, she has extended this important meeting to show the whole team the product/service lifecycle integrations she has been developing and testing out on a small scale. KS is now ready for more people to use the automated flow of work that her small DevOps team has created using the IT4IT Reference Architecture and existing tools in the application landscape.

NR also thanks the team for gathering the stakeholder information and translating it into the Architecture Vision, which will help the initiative stay on track and will be great input for the Business Architecture. He also mentions they have some good ideas for getting the Business Architecture done quickly, especially now that they have buy-in from the stakeholders and leadership.

NR presents the Stakeholder Map (Figure 20) and explains the process the team used to gather the information.

Presentation: NR and TG

NR displays a portion of a Motivation diagram identifying two of our stakeholder groups (the ArchiSurance Board of Directors and its current and potential customers) and their concerns, modeled as drivers. He points out that customer satisfaction is a shared concern of both groups; see Figure 21.

Stakeholder satisfaction can be refined into more detailed concerns, like profitability. The drivers motivate the development of specific business goals for profitability, as shown in Figure 22.

The two assessments show that the profitability of ArchiSurance is suffering from customers defecting to competitors with superior digital experiences or lower premium costs. ArchiSurance has a goal to raise its profit margin by 5% in the next fiscal year. Actions such as reduction of costs have a positive influence on this outcome. Cost reduction can be achieved by reducing both maintenance costs and personnel costs.

NR continues: Based on these business goals, a set of principles was defined to guide our architecture development. The ArchiMate modeling tool we are using [18] defines a principle as a realized, qualitative “statement of intent that should be met by the architecture”. Note that the systems here include, for example, organizations and organization units, not only IT systems. Principles, therefore, help realize business goals. The TOGAF Standard [19] also defines a principle as “a qualitative statement of intent that should be met by an architecture”, which should also have at least “a supporting rationale and a measure of importance”.

NR shows this modeled with the ArchiMate principles viewpoint (Figure 23), depicting principles, their dependencies, and the goals they realize.

From these principles, we have identified which requirements realize and/or influence them, which will be input for all development teams, helping us to understand the relationship between the work our stream-aligned teams are doing, and finally, the value it creates. The next slide shows the goal refinement for the Application Rationalization Strategy; see Figure 24.

With this information, we can prevent requirements being implemented without a clear link to value – or worse, deliver a requirement and only then realize it is not what we needed.

In addition to the short-term need for rationalization, we have started defining the longer-term Digital Customer Intimacy strategy that combines Big Data and IoT. Our stakeholders want to be able to use more detailed customer data to improve customer interaction and satisfaction, and to customize insurance premiums based on insights into the customer’s behavior. We intend to capture this data with smart, connected devices such as personal fitness trackers, black boxes in vehicles, home automation gateways, fleet management systems, in-store RFID devices, or smart sensors in buildings.

The next slide shows a strategy viewpoint; Figure 25.

TN takes over and presents her work on this viewpoint and the solution concept.

TN explains how she modeled an overview of the courses of action chosen or considered by the enterprise, the capabilities, and resources supporting them, the envisaged outcomes, and how these contribute to the organization’s goals and drivers. Ultimately, this new strategy should contribute to the main drivers of the organization, as outlined in part in Figure 20.

This strategy view (Figure 25) was developed to show the relationships between strategy, capabilities, envisaged outcome, and stakeholder drivers. The Digital Customer Intimacy strategy requires ArchiSurance to develop a number of new capabilities and resources (shown here in yellow), including digital customer management, data acquisition, and data analysis.

TN continues: An important element of the Architecture Vision is a high-level representation of the Target Architecture and how this provides a solution for the needs of the enterprise. It can really help explain the added value of the architecture effort to stakeholders. The TOGAF Solution Concept diagram can be created with the ArchiMate language for this purpose. Figure 26 highlights the most important aspects of the Target Architecture and how this will realize the expected outcomes, as shown in Figure 25. Figure 26 also adds the requirements for both the Rationalization and the Digital Customer Intimacy strategies; as you can see in the new solution:

TN outlines the next steps and presents a plan and timeline for the Business Architecture. We have identified an operational value stream that is called “Acquire Insurance Product” that we plan to build out with baseline and target models for each stage of the value stream. This would include a gap analysis and capability assessment for each value stream stage. The result will be a list of opportunities for each value stream that can be prioritized and placed on the roadmap. We estimate two to three weeks per value stream stage and the stages would be worked on simultaneously by our team of Business Architects. Each architect will be responsible for one value stream stage and a set of stakeholders. We also think it would help to assign a couple of Solution Architects who are well-versed in IoT and Big Data to work with us so we can get a head start on identifying solution alternatives.

KS thanks the team and says she is proud of the team’s progress and quality deliverables. She compliments Nick for showing leadership and initiative by going to the Vice-Presidents of the functional organizations for their buy-in and help with freeing up key resources to participate.

KS asks NR to work with TG to show continuous progress now that we have the buy-in.

ACTION: NR to work with TG to set up regular status meetings with key stakeholders and their leadership.

KS concludes the meeting by thanking the team again for all of their hard work stating that Business Architecture is key to the success of a Digital Transformation. With the Architecture Vision fully defined, it is time to start the Business Architecture.

KS asks for enough detail within the next two weeks to use it in the all-hands call Brad has organized, where she has been asked to present the vision that we have been building.

Meeting: The Business Architecture

Date: The next day

Present: Nick Ross (NR), Terri Nichols (TN), Rakesh Gupta (RG), Greg Morrison (GM), Philip Potter (PP), Jamar Johnson (JJ), Chris Keller (CK)

NR welcomes everyone and introduces the two Solution Architects that KS has assigned to work with the team. He explains his intention to assign a Business Architect to each one of the four value stream stages and, due to the linkages between the value streams, he is following TN’s suggestion of getting a couple of Solution Architects well-versed in IoT and Big Data to float between the teams to start putting together solution alternatives and have them ready by the end of the three weeks. NR also states that he anticipates a need to have at least a daily stand-up meeting to keep all of the architects in sync.

NR starts by going through a few diagrams he has put together to show the organizational view, see Figure 27 and Figure 28.

NR explains that an organization viewpoint focuses on the organization of a company, a department, a network of companies, or of another organizational entity. It is possible to present models in this viewpoint as nested block diagrams, but also as organization maps.

NR refers to Figure 27, which shows the high-level organization structure of ArchiSurance, with its main locations and departments. He will expand upon this later with an Organization Decomposition diagram and eventually traditional organization charts.

NR emphasizes, while on the subject of organization, that the cross-functional teams are as important as the toolset we end up with. He explains that the aim is to ensure a good flow of processes that will enable the best use of the toolset. He encourages the teams that as they work on building out the roles, processes, information, and tools as capabilities that enable their value stream stage, we will begin to see the roles that need to be included in the cross-functional stream-aligned team.

NR reassures the teams that we are already close with the teams that have been organized for the transformation and that it may be as simple as repeating the pattern for our other key company value streams.

He also explains that instead of having to transfer support from a project like we have in the past, the stream-aligned team will also become responsible for sustaining the solution. In other words, they will build the value stream and then support what they built to continue optimizing it.

NR presents the value stream map (Figure 29) the team would be using as it has a direct tie to the strategic theme “Digital Customer Intimacy”. NR and TG developed this value stream late last year with several key stakeholders but have not yet had the chance to build it out stage by stage.

NR explains that the value stream viewpoint allows the Business Architect to create a structured overview of a value stream, the capabilities supporting the stages in that value stream, the value created, and the stakeholders involved.

He points to the model of the main, high-level value stream for acquiring insurance products (Figure 29) and explains that it depicts three things:

NR shows his suggested assignment list to the team:

The team agrees that these assignments are good and that they are confident in their ability to meet the ten-day timeline to complete the Business Architecture and have opportunities identified. The last three days would be used to ensure the work is consistent across the value stream.

CK mentions that he has been working with Marketing for a couple of years, so this would be a great fit for him. GM says he feels positive about it as well, because he has been working with the Claims group for the past nine months on an initiative.

PP says he does not feel quite as confident, as Customer Service is a new area for him, but says he is always up for a challenge. PP has been reading a lot of Forrester^® articles to gain context in this area and, coincidentally, read one just last week where they mentioned the IT4IT Standard.

TN says she also saw that article and has also read a lot of books and articles in this area. She is very involved with The Open Group and the IT4IT Forum, so she offered to help PP with the “Serve Customers” value stage.

PP mentions that he could help her as well on the “Develop Products” assignment since it is one of his areas of expertise. NR asks if TN and PP should switch, but they decided they would prefer to keep the assignments as-is and would work together to ensure they are not missing any key aspects.

NR suggests that all of the team work very closely with each other to peer review each other’s work.

ACTION: TN to set up peer review meetings.

NR explains that the two Solution Architects – Jamar Johnson (expert on IoT) and Chris Keller (expert on Big Data) – will float between the groups.

ACTION: JJ and CK to be invited to all stakeholder meetings.

NR continues and presents the deliverables expected for each value stream stage:

NR shows the Business Capabilities that he and TN came up with when creating the value stream (Figure 30).

NR explains that ArchiSurance needs to improve or change several of its capabilities to implement the strategic and operational changes it envisages. This capability map was created to get a clear view of its current capabilities, inspired by the Panorama 360 Insurance and Wealth Management Enterprise Business Architecture Framework [29]. The capability map viewpoint allows you to create a structured overview of the capabilities of the enterprise. A capability map typically shows two or three levels of capabilities across the entire enterprise. It can, for example, be shaded to create a heat map that identifies areas requiring investment.

NR states that he would like a consistent format for the baseline and target state models.

ACTION: NR to schedule some time in a few days for us to get together and agree on the best template for consistency.

NR suggests a common template for the capability assessments in the form of a heat map. One he used in the past was color-coded to show red for capabilities that are significantly problematic, orange if they are problematic but not severe, yellow if they are suboptimal but not urgent, and green if they are in a good state.

ACTION: NR to bring the sample of a heat map to share before an agreement on the final template is made.

CK mentions that The Open Group TOGAF^® Series Guide: Value Streams [13] and The Open Group TOGAF^® Series Guide: Business Capabilities [28] might be a good place to look for industry best practice templates. He says that there are also ArchiMate guides that might help by providing some standard modeling techniques.

NR agrees and is keen to use standards that are already established. He and TN have used The Open Group TOGAF^® Series Guide: Business Capabilities, which is very much in alignment with the Business Architecture Guild^® guidance.^[15]

ACTION: All to look through The Open Group TOGAF^® Series Guides for possible ideas on how we can use the guidance to improve our architecture.

NR concludes by asking the team to think about how we should show our roadmap once we have all opportunities identified.

Meeting: The Results of the Business Capability Assessment and the “Manage Policies and Claims” Value Stream Stage

Date: August 27. Gold Conference Room, 2.00pm

Present: Kathleen Stone (KS), Nick Ross (NR), Terri Nichols (TN), Rakesh Gupta (RG), Greg Morrison (GM), Philip Potter (PP), Jamar Johnson (JJ), Chris Keller (CK)

NR welcomes everyone and begins with the results of a capability assessment that was conducted prior to the teams getting started on building out their assigned value stream stages.

NR shows that the Business Capability assessment (Figure 32) revealed significant problems in “Claim Settlement” and “Service Channel Management”. The technology enhancement capabilities “Data-Driven Insurance” and “Digital Customer Management” are also in the same two value stream stages. Based on these results, the team determines that we should focus on the last two value stream stages first. As a result, NR reassigns TN to work with PP on “Serve Customers” and RG to work with GM on “Manage Policies and Claims”.

The plan is to get these two value streams built out first and then re-evaluate whether or not we need to complete the other two value stream stages at this time for the Digital Customer Intimacy initiative.

This initiative is really driving the application of two new technologies (IoT and Big Data) into our environment to ultimately drive profitability for ArchiSurance through a best-in-class online customer experience.

NR presents a diagram he developed a few months ago with TN to show the main business functions of ArchiSurance, as well as the most important information flows between the functions and external parties. This diagram may help discussions with stakeholders.

NR displays the list of the main business functions distinguished by ArchiSurance:

NR then presents the business function viewpoint (Figure 33), which shows the main business functions of the organization and their relationships in terms of the flows of information, value, or goods between them.

PP says that this helps tremendously to see how the functional groups connect to our customers.

KS agrees that this is helpful for their stakeholder conversations.

NR introduces the sub-team presentations, starting with RG and GM on the Manage Policies and Claims value stream stage, followed by TN and PP.

RG starts by showing a slide with two central business processes of ArchiSurance (Figure 34). This diagram shows the high-level sub-processes: “Issue New Policy”, which is performed when selling a new insurance product, and “Handle Claim”, which is performed when a damage claim has been received. While the details of these processes may differ for the different types of insurance products, the main steps are essentially the same.

RG points out that the value stream stage is being realized by three business processes as depicted in Figure 35.

GM takes over the presentation and shows a partial requirements realization view. He explains that in Business Architecture, we need to show how the Target Architecture realizes the key business requirements. For this purpose, the TOGAF Standard specifies a Business Footprint diagram. In the ArchiMate language, this can be expressed using the requirements realization viewpoint. This viewpoint allows the designer to model the realization of requirements by the core elements, such as business actors, business services, business processes, application services, application components, etc. Typically, these requirements result from the goal realization viewpoint. Figure 36 shows how business requirements established in the Architecture Vision phase are realized by elements in the architecture for the “Handle Claim” process.

GM continues to the next slide to show that the Digital Customer Intimacy strategy of ArchiSurance also requires changes to the Business Architecture. First of all, new capabilities are needed, as previously identified.

GM moves on to present Figure 37, which shows these new capabilities in the context of the pre-existing “Policy and Claim Management” capabilities.

GM concludes the Policy and Claim Management presentation.

GM says they have also done a capability realization resource map with the entire team. TN and PP will present this on behalf of the team including the Solution Architects CK and JJ.

PP begins by explaining that he and TN had Digital Customer Management capabilities that are not in our existing environment but will be needed, as shown in Figure 38. He also points out that, as shown in the last presentation, the other value stream stage has a non-existent capability called “Data-Driven Insurance”.

PP continues by showing the joint capability realization resource map (Figure 39) that everyone worked on at one of the weekly meetings.

These capabilities require personnel with the right knowledge and skills for the digital age, smart devices for data acquisition, and the customer data itself. The resource map viewpoint allows the Business Architect to create a structured overview of the resources of the enterprise. A resource map may also show relationships between resources and the capabilities they support.

On the left-hand side of Figure 39 you see the capabilities and resources related to the Rationalization strategy, and on the right are those linked to the Digital Customer Intimacy strategy.

These resources themselves are realized by the rest of the Business, Information Systems, and Technology Architectures that are the subject of Phases B, C, and D of the TOGAF ADM. Figure 40 shows a small part of what this may result in.

PP points out that this does not depict all elements needed to realize these resources, it’s just a representative sample, again showing the implementation of the Rationalization strategy on the left and the Digital Customer Intimacy strategy on the right.

In practice, separate views will often be created to show how individual capabilities and resources are realized. CK’s and JJ’s experience with IoT and Big Data deployments really helped with the identification of the required competencies and the linkages to capability realization.

PP asks if anyone has any questions about anything in this presentation or the status.

KS says she doesn’t have any questions, but really likes how the team have identified the resource requirements early on for some of these new capabilities, as this often gets left to the end of an initiative and can cause implementation delays when resources are not available for the support of a new technology. KS is also very impressed with the diagrams and standard formats.

PP replies that lots of templates and examples were found in The Open Group Library, and that really sped up the work to represent the conclusions.

TN reminds the team that she and PP will have their value stream stage completed by the end of this week so it will be ready to present at the next status meeting.

Meeting: Team Status Meeting: “Serve Customer” Value Stream Stage

Date: September 3

Present: Kathleen Stone (KS), Nick Ross (NR), Terri Nichols (TN), Rakesh Gupta (RG), Greg Morrison (GM), Philip Potter (PP), Jamar Johnson (JJ), Chris Keller (CK)

TN welcomes everyone and begins by thanking GM and RG for the work they presented at the last meeting. She explained that she and PP took the format used as their starting point and embellished it a little.

TN asks for their input on that here, hoping that the team will all like our method for defining the processes within each value stream stage.

PP describes how they started by engaging the key stakeholders, which included Customer Relations and the Fulfillment Center. The Customer Relations group also provided some customer survey information that was representative of our customer’s point of view.

PP describes how they used a value stream stage definition template taken from The Open Group TOGAF^® Series Guide: Value Streams [13] to gather the information about our “Serve Customers” value stream stage.

PP explains that the template helped them to ask the right questions of the stakeholders and that then, using the definitions, it was easy to create the diagram of the process flow for the value stream stage.

Figure 41 shows the primary process flow developed for the “Serve Customers” value stream stage.

PP points out that above the process steps at the top, the assigned roles or functional groups are shown. A customer contact is the trigger for the “Manage Customer” process.

And just below the process steps are the data objects that are realized by the systems below them.

PP describes how working with the stakeholders, the following assessments, which tie back to the two original assessments, have been made:

PP explains that the earlier, top-level assessment (Figure 25) was that there are inefficiencies with internal operations, which ties well to our redundant CRM systems. They will need to be reduced to meet the requirement that was identified for a centralized CRM system. Another top-level assessment was that customers are defecting to competitors who have a superior digital experience. The reasons for this were evident in the most recent customer survey which revealed a large number of dissatisfied customers because of slow product fulfillment and the fact that we still have a lot of manual processes. Many of the surveyed customers said they wanted more self-service so they could resolve their issues. They disliked having to call into a service center only to be routed around trying to find the right person to help.

PP has asked cloud expert CH to take a look at these stakeholder assessments.

CH is confident that we can resolve these threats and weaknesses with a cloud solution that will help us automate the manual processes and increase fulfillment cycle time. The cloud solution can also serve as a portal to our customers as we begin to consolidate CRM systems on the backend.

TN asks if there were any questions on their team presentation on the “Serve Customer” value stream stage definition.

GM says he has no questions but really likes the way PP and TN defined the “Manage Customer” process and the way they linked assessments to our earlier higher-level assessments.

GM also expressed how impressed he was with the techniques they found in The Open Group TOGAF^® Series Guides, which the whole team can use in architecture engagements going forward.

NR asks if the team is agreeable to standardizing how we model our baseline and target states for each value stream stage in the way TN and PP have shown, as it really shows the connections between the process, roles, information, and tools.

KS concludes by telling everyone their work is fantastic. She says she’d been nervous at the start, but is now confident that with this material she can present the company vision and the architecture intent in the all-hands call next week.

KS gives a heads up that she is going to schedule a working meeting for the team to update the roadmap to capture all the work done so far and get the high-level opportunities plotted and reviewed at our next stakeholder meeting.

NR says that is an excellent idea. He says that the team has been researching ways of displaying the roadmap and that they have some ideas already sketched out that can be brought to the table to give the stakeholders a timeline that shows the architecture transitions with a view to getting some commitments and setting some target dates.

Meeting: Information Systems Architectures and Technology Architecture

Date: October 8

Present: Kathleen Stone (KS), Carl Highfield (CH), Nick Ross (NR), Terri Nichols (TN), Rakesh Gupta (RG), Greg Morrison (GM), Philip Potter (PP), Jamar Johnson (JJ), Chris Keller (CK)

CH begins the meeting and says he cannot believe how quickly we have been able to put together the Solution Architecture for this important initiative. It is a tribute to the great work on the part of the Business Architects who have done a fantastic job of understanding our gaps and prioritizing the opportunities with the business so we have a solid roadmap and transitional plan by plateau. Also, CH is impressed by the reference architecture developed by CK last year. It really enabled us to go fast.

CH introduces CK, who will lead us through the Information Systems Architecture.

CK begins by thanking KS and CH for the opportunity to work on this incredible initiative that will change the way business is done at ArchiSurance. He also wants to mention that we really need to ensure that we have good Architecture Runways available for developers when they are planning MVPs. For some reason, they think that the architects are always trying to put up roadblocks. The truth of the matter is when they go around us they often go down a path that results in a working MVP that will not scale in our environment. If we had a good runway in place, the environmental, security, and policy constraints would be known up-front versus finding out much farther down the road. They would also have a better understanding of the quality attributes required to make their MVPs scalable and consumer-friendly. CK recommends that we need to work on our relationship with DevOps and gain their trust by giving them enough runway in a timely manner that allows them to develop quality MVPs. That means that we need to stay involved as they go through their development Scrums instead of dropping off an initial architecture and then leaving.

CH agrees wholeheartedly.

JJ says he has been thinking about this as well and is more than willing to work side-by-side with the developers through Scrums to advise them when they are making a decision that will bite them later.

There is full agreement.

CK presents Figure 42, the application cooperation viewpoint, which describes the relationships between application components in terms of the information flows between them, or in terms of the services they offer and use. This viewpoint is an overview of the baseline application landscape of the organization. It is used to express the (internal) co-operation or orchestration of services that together support the execution of a business process.

CK shows the target application cooperation viewpoint (Figure 43), created to show Business Process to Application alignment. It describes how applications are used to support one or more business processes, and how they are used by other applications. It can also be used in designing an application by identifying the services needed by business processes and other applications, or in designing business processes by describing the services that are available. Since it identifies the dependencies of business processes upon applications, it may be useful to operational managers responsible for these processes.

The behavior of the data warehousing solution, in the context of data acquisition on the one hand and the business processes and functions on the other, is shown in Figure 44. The insurance premium of individual customers is based in part on the data they acquire from different devices. This data is processed to create customer-specific profiles that are input to the calculation of their insurance premiums. At an aggregated level, this data is also used to develop new kinds of insurance products and to assess and adjust the overall risk exposure of the company.

CK moves on to show the results of a global gap analysis for the Application Architecture (Figure 45). Several application components that exist in the Baseline Architecture are no longer present in the Target Architecture: the separate back office applications and the separate “Legal Expense CRM System” and “Legal Expense Back Office System”. The CRM functionality for Legal Expense insurance customers is taken over by the general CRM system; therefore, this does not require new components (although it may be necessary to adapt or reconfigure the existing general CRM system, this is not shown in the gap analysis). In addition, a completely new back office application suite and new data warehousing solution are introduced.

CK continues by talking about the ArchiSurance Data Architecture which describes the major relationships between its conceptual business objects and its logical data objects. The information structure viewpoint is comparable to the traditional information models created in the development of almost any information system. It shows the structure of the information used in the enterprise or in a specific business process or application, in terms of data types or (object-oriented) class structures. Figure 46 shows a subset of the business objects that ArchiSurance defines. Part of the customer information is an insurance file, which is composed of insurance requests, insurance policies, and damage claims. A number of specializations of the Insurance Policy object are defined, one for each type of insurance that ArchiSurance sells.

CK goes on to say that the purpose of the Data Dissemination diagram (Figure 47) is to show the relationships between the data entity, business service, and application components. The diagram shows how the business objects are realized by application components. This allows effective sizing to be carried out and the IT footprint to be refined. Moreover, assigning business value to data gives a clear indication of the business-criticality of each application component.

CK says this is a great opportunity and asks if there are any questions on the Information Systems Architectures.

PP asks if CK has identified all of the information security policies that are relevant for the data that will be collected about our customers.

CK replies that he believes all of the information security policies have been identified in the Enterprise Architecture system. They were easy to find as we adopted recent improvements in the IT4IT Reference Architecture, so our product/service lifecycle now captures information from the conception of an Idea through to Operations. CK reports that he has been working with the GRC group on the information security plan for about three weeks. The plan explicitly states how we will adhere to each policy.

CK emphasizes the need to have a bulletproof plan for protecting our customers’ personal information.

PP is glad to hear that CK is so far along on the information security plan.

KS agrees and points out that CK is also in line with our first two principles:

CK hands over to JJ to go through the Technology Architecture.

Next, we created a visualization of the results of a global gap analysis we ran for the Technology Architecture (Figure 52). The separate general-purpose back office servers are slated for removal. The original server cluster of Home & Away is to become the central ArchiSurance back office service cluster, and an additional backup server cluster is to be placed in the SSC at PRO-FIT headquarters. A backup document management server is also to be placed in the Home & Away back office. The new back office suite and the document management system are to be replicated on their respective main servers and backup servers.

JJ asks if there are any questions about the Technology Architecture.

GM asks about information security and the cybersecurity implications for IoT.

JJ replies that cybersecurity is taken very seriously. He has also been working on the security plan, with a whole section on IoT device compliance. A key requirement is the ability to track these smart devices on the network, and to know where they are in case of a cyberattack that would require them to be removed from our environment. Since last year, supplier contracts demand that they must notify us if a product has a cybersecurity issue. We are considering the purchase of software that gives the latest updates on cybersecurity issues with IoT devices. JJ asks if there are any other questions.

KS tells both CK and JJ she is very impressed with their work.

Meeting: Digital Customer Intimacy Enterprise Architecture Team for the Opportunities & Solutions and Migration Planning

Date: October 22

Present: Kathleen Stone (KS), Carl Highfield (CH), Nick Ross (NR), Terri Nichols (TN), Rakesh Gupta (RG), Greg Morrison (GM), Philip Potter (PP), Jamar Johnson (JJ), Chris Keller (CK)

CH starts by saying that after the work group has been meeting twice a week for two weeks, he is pleased with the format the team came up with for representing the roadmap. An architect can easily trace the opportunities back to the architecture transitions, but it is also easy for non-architects to follow.

CH continues by showing a migration viewpoint (Figure 53). It involves models and concepts that can be used for specifying the transition from an existing architecture to a desired architecture. Specifically, it shows an example for the current scenario. Our IT department does not have sufficient resources to carry out the standardization of the back office systems and the integration of the CRM systems in parallel. One Transition Architecture therefore replaces two CRM systems with one, but with separate back office systems. Another has a single back office suite but two CRM applications. After that, the data warehousing and IoT solutions will be implemented.

CH continues by saying that Transition Architectures enable the planning of implementation projects such as “CRM System Integration” and “Back Office System Integration”.

The sequence of these projects depends on which of the Transition Architectures is selected. We used a TOGAF Project Context diagram (Figure 54) to show this.

This type of diagram shows the scope of a work package to be implemented as part of a broader transformation roadmap. It links a work package to the organizations, functions, services, processes, applications, data, and technology that will be added, removed, or impacted by the project.

CH finishes his presentation by showing a draft roadmap (Figure 55). He says it may change a little as we get it out for review, but we do have the architecture phases and development iterations defined. The work has been accelerated and informed by both the TOGAF Standard (shown in yellow) and the IT4IT Standard (shown in blue), which also supported us in doing some automations. The kickoff and go-live are highlighted in green, the work packages that we defined as part of the architecture are plotted in pink, and some additional activities identified as part of the organization map are in gray.

That is a wrap on the Opportunities & Solutions and Migration transition plan for the Digital Customer Intimacy strategic theme. As shown, we have lots of initiatives for our first Digital Transformation. Some of the initiatives, like the product/service lifecycle improvements and the application rationalization, are foundational so the next digital initiative will go much faster.

CH praises the team. Excellent teamwork on all of the architecture domains, saying he really thinks we have a great plan and plenty of runway for the DevOps team.