AT#36: How to be Successful with Strategic Information Technology Landscape Planning

AT#36: How to be Successful with Strategic Information Technology Landscape Planning

We have written many posts at the Architectural Thinking blog that deal with the business aspects of architecture. Business architecture is at the core of Architectural Thinking and must be connected to vision/strategy and solution development. Business architecture drives IT architecture, not vice versa. This doesn’t mean, however,  that the technology landscape of a company does not need to be governed! Technology is the basis that supports applications that support the business as shown in the meta-model of the Architectural Thinking Framework: Read More

AT#34: How to be Successful with Application Landscape Planning

AT#34: How to be Successful with Application Landscape Planning

We have written many posts at the Architectural Thinking blog that deal with more strategic topics like vision, strategy and business architecture and how to connect this to solution development. The common aim defines the direction the company shall go, based on a vision statement created by executives. After that, business architecture comes into play and make the vision more operational. The upcoming posts show how strategic planning of the application & technology landscape can be operationalized using two simple architecture maps: application map and technology map.

Read More

AT#27: Capability Modeling Crash Course – Elicitation Recipe

AT#27: Capability Modeling Crash Course – Elicitation Recipe

Last week we completed our three-post crash course. We received lots of feedback and questions about how to elicit capabilities with the business people. The blog series reached an audience of thousands of people. For that reason, we decided to add a fourth – “da capo” post.

The previous post in this blog-series discussed why capabilities are the invaluable core of Architectural Thinking, how to use your existing process- or value stream maps and how to structure capabilities. Today we present how capabilities should be elicited by the business architect by a broad participation of business stakekholders.  Enjoy!

Read More

AT#26: Capability Modeling Crash Course Part 3

AT#26: Capability Modeling Crash Course Part 3

Capability modeling seems simple but is hard to do in practice. If you browse literature or the internet you’ll find only very little advice. No ‘Capability Modeling Guide’ out there. To change that, the Architectural Thinking Framework includes a draft of detailed guidelines that show how to model capabilities step-by-step.

Last week we discussed how to apply industry-specific capability reference models and how to use your existing process- or value stream maps. Today we provide step-by-step instructions to design a map that is easy to be understood by business stakeholders. Enjoy!

Read More

AT#25: Capability Modeling Crash Course Part 2

AT#25: Capability Modeling Crash Course Part 2

Capability modeling seems simple but is hard to do in practice. If you browse literature or the internet you’ll find only very little advice. No ‘Capability Modeling Guide’ out there. To change that, the Architectural Thinking Framework includes a draft of detailed guidelines that show how to model capabilities step-by-step.

Last week we defined the term ‘Capability’ and discussed why they are invaluable. Today we continue our series with part 2 of 3. Enjoy! Read More

AT#24: Capability Modeling Crash Course Part 1

AT#24: Capability Modeling Crash Course Part 1

In recent years, the idea of business capability modeling has emerged in the EA community. Much has been written about the idea of capability modeling, and it can even be said that we are facing a ‘capability hype’. You can find capability models for many industries on the internet. There are many industry-specific consortiums that try to model the business functions of that particular industry in the form of capabilities.

Capability modeling seems simple but is hard to do in practice. If you browse literature or the internet you’ll find only very little advice. No ‘Capability Modeling Guide’ out there. To change that, the Architectural Thinking Framework includes a draft of detailed guidelines that show how to model capabilities step-by-step.

Today we start a series of three blog posts that provide a capability modeling crash course. It includes the experience of ten years of trial and error in several companies and review by many practitioners.

 

Definition: Capability

A business capability is a core of ‘what’ a business does, a technique for the representation of an organisation’s business anchor model, independent of the organisation’s structure, processes, people or domains [GartnerGlossary]

Read More

AT#15: How to make decisions in uncertain Times

AT#15: How to make decisions in uncertain Times

To deal with the challenges of the VUCA world, many companies experiment with shifting the idea of agility, as broadly used in software engineering practices in form of e.g. SCRUM to the whole organization. [J. Eckstein: ‘Company-wide Agility’, 2018] gives an overview of more than twenty different approaches for the agile organization. Browsing through these approaches, some of their proponents seem to propose that all decisions should be made decentralized by autonomous teams. Use the knowledge of the many and you will get the right solutions.

But that is far from true.

Grassroots democracy is not a model for companies.  An organization pursues particular business goals dictated by shareholders, the autonomy of the employees is not its primary concern. Which application server software a company chooses to use is not a subject of general elections.

All approaches proposing the agile enterprise do not take one thing into account: architecture. Building solutions in a sound architectural form needs common elements and ‘conceptual integrity’. This means that the concepts and structures of the business (capabilities, value streams, products & services, business objects) and IT (technology components) must play together in a way that maximizes simplicity, consistency, agility and thus business value. Read More

AT#13: Companies are Elephants!

AT#13: Companies are Elephants!

The famous parable of the blind men and an elephant is a story of a group of blind men, who have never come across an elephant before and who learn and conceptualize what the elephant is like by touching it. Each blind man feels a different part of the elephant’s body, but only one part. They then describe the elephant based on their limited experience and their descriptions of the elephant are different from each other. The complete text of the poem is here.

When I read the parable I instantly found it to be very suitable to use it for companies within the digital transformation. Companies are elephants employing blind men like: Read More

AT#11: Build strong connections between Solution- and Enterprise Architecture!

AT#11: Build strong connections between Solution- and Enterprise Architecture!

In most companies I know, enterprise-wide architecture models are designed by a few enterprise architects and are typically not widely accepted by developers. Today, agile solution teams and enterprise architects are separated by huge walls of ignorance and misunderstanding. Enterprise architects (EAs) manage their repository of artifacts and build to-be roadmaps. Solution teams do not care about the work of the EAs and do whatever their product owner wants them to do. Strong links between solution architecture and enterprise architecture seldom exist, which questions the use of the latter at its very core.

What you should do: Read More

AT#9: Three Values that make your Enterprise Architecture Management successful

AT#9: Three Values that make your Enterprise Architecture Management successful

For sure, Enterprise Architecture Management (EAM) is still a very immature, weakly defined field. Most of the methods, tools, and frameworks suit the requirements of real-world projects only to a small degree. Most of the elements EAM tries to structure and manage towards a to-be state’ are abstract and hard to grasp. Archimate®, a modeling notation for EAM, for example, defines more than thirty elements, most of them are vague abstractions and far from tangible. In practice, EAM is much more focused on designing application landscapes than providing a holistic view of the enterprise. EAM is still very much about ‘application portfolio management’ that tries to minimize IT costs without alignment to the business capabilities.

But how can this sad situation be changed?

Our suggestion is to apply three values to your EAM practice: Read More


1 2
close

Please spread the Ideas of Architectural Thinking!