The Turning Point: A Novel About Agile Architects Building a Digital Foundation

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 Information Systems Architectures and Technology Architecture).

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^[1] 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 IT4IT Reference Architecture Adapted for Use in ArchiSurance 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.