Do you know the weak points of your IT architecture and how to get rid of them?
Have you ever asked yourself, how to define an IT Architecture for your enterprise that fits best to the heterogeneous requirements of your different stakeholders?
If you are an IT guy: Have you ever had the necessity to defend your implemented IT architecture against complaints that the real business needs are not considered well?
If you are a business guy: Have you ever had this feeling that translating your business needs to the IT department is a difficult task? Or have you wondered how you could find a common way of communication to cooperate with IT?
And by the way have you ever wondered, why it is quite often not easy to find and gather all the information that is needed in order to taking conscious decisions and aligning on the right architecture? And this certainly includes the fact to get the relevant information from SAP, if SAP products are involved for the IT architecture.
If one of these questions sounds familiar to you, you are definitely reading the right blog. You might not find the silver bullet for all challenges, but you will get some insights about our new approach supporting customers in defining the right IT architecture for their enterprise.
Challenges
Let us first have a look at the challenges when designing the optimal IT architecture within an enterprise from ten thousand feet height. The following picture illustrates a high-level proceeding to define a target IT architecture supporting the business:
Different stakeholders need to be involved, coming from business areas, headquarter, IT, etc. They have to collect and provide all relevant information that is required to prepare a decision about the optimal IT architecture. Optimal is seen in the sense that it is supporting IT and business needs best.
This proceeding faces a lot of challenges, just to mention some of them:
- You need to have all relevant stakeholders involved.
As there are various stakeholders with diverse responsibilities required, you need to be sure that you really reached them all.
- You need to mediate between heterogeneous concerns.
Different stakeholders often come with different and heterogeneous concerns using different “vocabulary”. Achieving a common understanding and an alignment across these interests is obviously difficult to achieve. (If you are thinking about your last meeting with people from different areas in your company, I am pretty sure you know what I am talking about.)
- You need to maintain, store and keep information up-to-date.
To take the right architectural decisions for your enterprise, you have to have an accurate understanding of your environment and its needs. Unfortunately, on your way to get this understanding you will need information that often comes fragmented & incomplete and is usually cumbersome to gather.
- You need transparent & traceable decisions.
The final decision about the targeted IT architecture needs to be transparent & traceable within your enterprise. Also the impact it causes on business and IT needs to be clear. At the end of your journey, every relevant stakeholder in the company needs to be aware of the main drivers that led to the chosen IT architecture. Even after years, when people who were involved in the decision changed the organizational unit or even left the company.
- You need to find a balance between conflicting demands.
Who did not experience requests to optimize an architecture into different competing directions like flexibility, innovation, stability and cost reduction? Gartner described this dilemma that there is no one-size-fits-all solution in the pace-layering approach . At the end your IT architecture must consider business and IT needs, balance conflicting demands, and allow a safe transition from current to target state.
How could an approach look like to manage the mentioned challenges and make defining IT architectures smoother?
I am sure there is no single answer to these questions and it is a big wheel to turn. There are a lot of different enterprise architecture approaches in terms of frameworks, methodologies, processes or taxonomies available. However, it seems that there is no single approach that helps to solve every challenge or that fits to every customer situation (you will find some interesting thoughts in this blog by Roger Sessions).
Thus let us talk about some ideas how SAP could help in this game.
Expectations & Goals
The challenges described so far do not only pop up for an enterprise internally, but appear in almost the same manner for the communication between SAP and you as a customer.
It is a challenge for us (SAP) to
- provide the right stakeholders at customer side
- with the relevant information to support them
- taking balanced decisions about
- the optimal IT architecture that best supports their business goals.
Well, I could also phrase it from the other side’s perspective:
It is a challenge for you as a stakeholder at customer side to get the relevant information from SAP that you need in order to decide about the optimal IT architecture that best supports your business.
I think we should avoid:
- that a CIO has to read pages over pages of detailed product documentation (even of multiple products) to find the supporting information for defining an IT transformation strategy,
- that an enterprise architect needs to read complete installation or master guides to get an idea about the architecture of a new SAP product that needs to be integrated,
- that a solution or project architect gets surprised about an unexpected product behavior that was not considered in the planned solution architecture, or
- that an system administrator has to deal with unknown side-effects like software dependencies with other installed products when installing or updating a certain product.
As you already see, architecture has different facets and different stakeholders have different concerns and need different kind of information to derive “their” architectural decision. However, at the end of the day all pieces must fit together. And the target architecture needs to reflect the views of all stakeholders: from CIO via enterprise architect and solution/project architect to infrastructure architect and system administrator. And most important the IT architecture must reflect the business needs.
Hence I think what we need to achieve is the following:
Goal 1: The right content
We need a clear perception and transparency about the kind of structured information artifacts that help to take architectural decisions in the sense as mentioned above. Examples are:
- architecture patterns to describe different design options and their pros and cons,
- reference architectures to offer reusable designs,
- best or common practices to provide guidance, or
- methodologies to ensure consistency and traceability of decisions.
Goal 2: The right structure
We need a structure that allows to organize these information artifacts along their main architectural perspective & stakeholder view. For example CIO guides on a strategy level, reference architecture on a capability level, landscape deployment recommendations on a software product level, or sizing methodologies on a physical installation level.
Goal 3: The right relations
We need a possibility to connect different information artifacts within the structure showing the impact to each other:
- Either to connect important cross topics like landscape architecture and integration architecture on the same architectural perspective (e.g. to relate a landscape strategy to an integration strategy).
- Or to illustrate the influence of different architectural perspectives on each other (e.g. to link the different perspectives of an UX (user experience) strategy, for this purpose required UX capabilities, and the corresponding UX related software product components and their implementation tasks).
Goal 4: The right access
Finally we need a simple and stakeholder-oriented consumption of these information artifacts. Every stakeholder needs an easy access to the information artifacts that addresses his or her architectural needs.
Let me make something plain at this point. It is not the intention to invent another enterprise architecture framework. I believe there are enough alternatives available in the market and companies need to find the one that fits best for them. The structure mentioned in Goal 2 shall help to keeping the right focus on the different architectural perspectives. And it shall simplify to getting the right information from SAP for certain architectural decisions. This information can be used for any kind of enterprise architecture framework (as it is depicted in the picture below).
In the next parts of my blog I am going to explain, how we are planning to support you in reaching the mentioned targets:
- SAP Managed Tags:
