Digital Transformation: Architecture Value

I first met Paul Harmon late last century when we worked together at a small, enterprise solutions consultancy. Our first collaboration grew out of that when we published the book “Developing E-Business Systems and Architectures: A Manager's Guide” in 2001. And while obviously the technology, business and operating models have changed and evolved dramatically, the architectural foundations that we laid out in that book have withstood the test of time.

The consulting company was acquired, and we took separate paths, but through BPTrends, have kept the collaboration going. My first article was in 2003 as a guest writer to the “MDA Journal” column with “MDA, SOA, and Technology Convergence”. Then, I kicked off the Service Oriented Architecture (SOA) column in January 2006 with “BPM and SOA: Where Does One End and the Other Begin”. Twenty articles later, in 2011 I concluded with “SOA and the Cloud”.

It was time to move on to something new so in 2012, I put SOA to bed and started the Business Architecture column with “Introducing Business Architecture”. This column included not just Business Architecture, but some of the foundational skills of architecture with “Understanding Why, How, and How Well” about measuring outcomes and the Business Motivation Model. “Abstraction in Business Architecture” covering the fundamental skills and concepts of abstraction, and “Critical Thinking in Business Architecture”, a skill that is key to good architecture and analysis, and all too lacking in the world today. After nine articles in this series, I took a job as an industry analyst and had to curtail my contributions to BPTrends.

In 2018 I “semi-retired” from my analyst position and came back to start my current column with “Digital Transformation: Right Here, Right Now” and continuing with topics such as “Turning Data into Value”, “BizOps” and the “New Normal”.

Finally, 2022 kicks off another change, moving from semi-retired, or as my wife put it “failing to retire”, to “actually retired”. This will be my last article for BPTrends as I focus on enjoying my family, friends, house in the woods, travel, woodworking, skiing, and more. I've truly enjoyed working with BPTrends, responding to the occasional emails I get from readers, and especially meeting people at conferences such as BBC who say: “I read your article on BPTrends…”.

In the 38 articles I've written over the past 18 years, the overarching theme has been architecture, so I'll finish up with one more thought: What is the value that architecture brings – to projects, organizations, the enterprise? Well, as an analyst, I had the opportunity to discuss architecture with 100s of CIOs and do some in-depth interviews with a dozen or so that had what I would consider successful and effective architecture programs. From that, I narrowed it down to one key value: Transparency

Transparency into what you have today
Transparency into options you have for the future
Transparency into directions you should not be taking
Transparency into how you are, and should be, investing
Transparency into the impact of your decisions

And to the many who will argue that today, things are changing so quickly that long term plans are a thing of the past, I have two answers:

It's an incorrect assumption that architecture is about long-term planning and stability. Today, architecture is about providing a flexible, scalable, secure platform of business and technology that allows for rapid innovation and growth. Architecture fits naturally into modern DevOps, or better yet, BizOps environments where enterprise cultures support innovation, autonomy, and structure. This is how the leading technology giants operate.
I like this quote attributed to General Dwight D. Eisenhower: “In preparing for battle I have always found that plans are useless, but planning is indispensable.”¹ It is architecture that is the act of planning that gives us the ability to pivot, with transparency, into what is possible and what it may impact.

Unfortunately, legacy perceptions of architecture will persist, and successful architecture programs will be the exception rather than the rule until architecture as a profession shifts focus. For the past two decades, I've been saying that “Creating architecture provides no value. Value is only realized when architecture is used to influence decisions”. So how do we create architecture to influence decisions?

We'll, the first question is: “What decisions are you trying to influence?”. We get to this through a series of further inquiry:

What are the enterprise goals and strategies?
What decisions require an architectural approach to achieve those goals? (This will be enterprise and strategic decisions that require consistency across boundaries)
What are the expectations of architecture? (from leadership, sponsors, stakeholders)
What decisions can architecture realistically affect? (politics)

We must realize that architecture, by its nature, imposes constraints. Those constraints are for a good reason, and have value, but they are constraints none the less, and by some are perceived as a burden. There is a basic formula for architectural acceptance that says that the value that architecture delivers has to be greater than the burden (real and perceived) that it imposes. So now, we want to follow the principle that I call “Don't sweat the small stuff”. Only the minimum number of most important, architecturally significant decisions should be the focus of an architecture program. While there are dozens, or even hundreds of things that architecture could try to do, it will only be successful with a small number. I like to start with five major things. And remember that architecture is done at different scopes, so five major enterprise things would be the domain of a central architecture group, while five application-level things might be the domain of a solution architect. Beyond a small number, it becomes difficult, if not impossible, to come out on the plus side of the value / burden equation, and the architecture program struggles, or fails.

Okay, so we've identified the decisions that we're trying to influence and now it is time for my last saying, the architecture success formula. “When you make it easier / better for someone to do their job by using architecture, they will. If you make it harder for them, they won't”. It really is that simple, but of course, achieving it is easier said than done. My approach is by exploring these questions?

Who makes those decisions?
What processes do they use to make them?
Where are the opportunities within those processes to influence the decisions?
What structure of artifact would be useful:
- At that point in the process
- For that individual
- From their perspective, tools, and skill set?
- …And consistent with architectural principles and best practices!
How do we make one? How do we engage them to help?
How will we measure if it is working?

In other words, the key to successful architecture is working with critical stakeholders to help them make better, architecturally influenced decisions, by providing them with information that is structured in a way that in natural to them and helps them do their job better. Try it…it works.

It has been a real honor and pleasure to be a contributor to BPTrends for all of these years. I have tried to share what I've learned in my 40+ years of technology as well as my passion for architecture, continuous learning and curiosity coupled with critical thinking. I hope that in some small way it has moved the profession forward and especially, has been helpful, informative, and enjoyable for you. If so, drop me a line or connect on LinkedIn. My very best to all of you! Cheers.

¹ I prefer this version of the quote which was published in 1962 in the book “Six Crises” by Richard M Nixon where he attributed the saying to Eisenhower. Other versions of the saying appear in a letter written by Eisenhower in 1950 and a speech he gave in 1957.

PDF Version

Bio
Latest Posts

Mike Rosen

Mike Rosen is Chief Scientist at Wilton Consulting Group and a Founding Member of the Business Architecture Guild. Mr. Rosen is also an Adjunct Research Advisor for Business and Enterprise Architecture for IDCs CIO Advisory Practice. He has more than 30 years of technical leadership experience architecting, designing, and developing software applications and products. Currently, he provides expert consulting services in the areas of Enterprise Architecture, Business Architecture and SOA. Previously, Mr. Rosen was CTO at AZORA Technologies and M2VP, Inc., and Chief Enterprise Architect at IONA Technologies, PLC, and Genesis Development Corporation. Mr. Rosen was also a product architect, technical leader, and developer for commercial middleware products from BEA and Digital. His involvement in product development includes Web services, Java, CORBA, COM, messaging, transaction processing, DCE, networking, and operating systems.