
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.
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:
As there are various stakeholders with diverse responsibilities required, you need to be sure that you really reached them all.
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.)
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.
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.
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.
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
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:
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:
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:
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.
We need a possibility to connect different information artifacts within the structure showing the impact to each other:
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:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
13 | |
12 | |
9 | |
8 | |
7 | |
7 | |
7 | |
6 | |
5 | |
5 |