Architecture for Digital Business: An Interview with Mike Rosen
Mike Rosen’s Cutter Consortium webinar “Architecture for Digital Business” explored how to support your business transformation by taking an architectural approach to strategy. Here are four questions we asked Mike at the end of the webinar that you may also be considering:
Q1: With an increasing focus on Agile digital delivery and incremental delivery, how can they be tied into the conversation of architecture for digital business? How should it be architected, and how can you start bringing it to live delivery incrementally?
MR: There’s a couple of answers to those questions. We can enhance typical DevOps and Agile environments by using business architecture to help feed the backlog queues, then what’s been fed into the backlog really has been vetted to align with strategy and prioritized by value delivery. There’s a big opportunity for us to improve the DevOps environment by adding business concepts and concerns and strategic alignment into that cycle.
There are a bunch of other things we must do as architects to fit into that environment. First off, we must realize that the DevOps environment is not really going to change to adopt traditional architecture. The Agile ethos is not going to change to adopt traditional architecture. By and large, we have to change the way we do architecture. We have to create and specify architecture in little modules that fit into stories that can be implemented in sprints. We have to provide a test-driven environment to validate that things are conforming to architecture. We need to understand how to provide immediate feedback to scrum teams as part of the daily standup when they have architectural issues.
There’s a variety of different approaches that we’ve taken that have been successful in integrating architecture into a DevOps environment. Most of them involve having architects think like DevOps people. If we think that way — and I’m going to say we have to because DevOps and microservices and Agile are the way things are going, and if we want to be part of that, we want to make sure that what we’ve developed is not only quick, but is also the right thing to be delivering — then we need to make those changes.
Q2: Today, many seem to think that intentional architecture planning is passé and, if necessary, it should emerge on the fly. Do you have any thoughts on that?
MR: Some architectural planning can emerge on the fly, but there are a lot of things that we can do in advance. If your organization is about building a microservice environment that is going to scale to support millions of customers, and you know that over time you’re going to need certain kinds of artificial intelligence, automation, and machine learning capabilities as part of that architecture, that intentional architecture can evolve and be developed with some forethought in advance of it being needed by the business. And there’s a lot of understanding of how to build those things already.
To meet evolving business requirements, some aspects of the architecture should evolve at the same time, or evolve one or two sprints in advance, so that it’s mostly in place when it’s needed. But to say “I’m just going to invent how to do microservices over time as I need it” is kind of foolish because we already know how to do it. We know what’s going to be required. We know what we must put in place. Aspects of it can evolve, but to declare that all thinking ahead is passé, some things we know we’re going to need, and thinking ahead provides much better results.
Q3: Is there a checklist or template an organization can use to gauge where they are on the transformation journey?
MR: Personally, I don’t like using a checklist or template. The reason for this is because every organization is different. Every organization has different skill sets, cultures, requirements, resources, and goals. I find that a more flexible, agile, personalized approach to understanding what an organization is trying to achieve, and what they need to do to get there, provides better results than a template. Templates and checklists are personally not my style.
Q4: When is it optimal to consider the impact of team velocity between DevOps or architecture planning?
MR: I try to factor business features and architectural enablers into the backlog. Then, team velocity is going to determine how quickly we can implement those different features or enablers. The goal is to have the enablers build one or two sprints ahead of the features that require them. So, velocity is going to determine how long it takes to create something, and if we’ve done a good job of breaking the architectural enablers down into sprint-size pieces, it fits well into that planning model. So, as opposed to velocity being a critical aspect of that decision, the question is more about how do we make sure we prioritize the stories so that the intentional architecture is in place when we need it, and it’s implemented within some reasonable 10%-20% of our overall backlog.
Cutter Consortium welcomes your comments about this Advisor. Please send your comments and insights to us at email@example.com.
More Articles Like This
- Cognitive Computing, Part II: Commercial Cognitive Platforms and Services — Executive Summary
- Cognitive Computing, Part II: Commercial Cognitive Platforms and Services
- The Next Frontier in Automation: Opportunities, Challenges, and Impact — Opening Statement
- Technology-Empowered Solutions: Redefining Decision Support — Opening Statement
- Architecture for Digital Business