
Let us have a closer look now, how the expectations raised in the first part of my blog could be met. The following picture illustrates an information structure that reflects the different views of stakeholders on IT architectures.
There are four abstraction levels to provide different important views.
The main idea here is to focus on that kind of information that helps to set the frame and right priorities for the overall IT architecture within the company. It shall cover information to answer questions like:
The deliverables of this level shall be IT specific (meaning concrete guiding principles for IT), but aligned with and driven by the business.
Business needs are mapped to application and technology capabilities within IT. These IT capabilities are required to support the business architecture. Information is needed to deal with questions like:
Reference architectures, architecture patterns or common architectural principles need to be defined for the enterprise. These rules shall provide guidance for any concrete software product that is chosen and implemented within the company.
Thus this level targets the design principles of IT architecture within the enterprise on an IT specific, but still software product agnostic level. This includes a SAP agnostic view as well.
Now product-specific aspects and principles are in scope. Questions like the ones listed below need to be considered for taking the right architectural decisions:
This architectural analysis is product-specific (and therefore also SAP-specific for SAP products), but can be considered independently from the concrete physical installation on hardware boxes.
The lowest level of the structure targets all architecture related decisions about the physical installation of software packages on hardware boxes (including possible virtualization layer in between). Information is needed to clarify aspects like:
Hence the impact of the specific infrastructure on the IT architecture need to be considered. Architectural decisions taken before need to be verified and checked for their technical feasibility.
Let me outline, how this structure of four abstraction levels simplifies to identifying relevant information and taking architectural decisions.
Think about the following little example. You have heard about SAP’s new user experience (UX) approach SAP Fiori:
However, for me it looks a bit cumbersome to start reading installation guides or searching at many different places and collecting additional product documentation . It is at least cumbersome for the purpose of gathering the relevant information to take architectural decisions as described in the chapters before.
Wouldn’t it be much nicer to have a structure available
Let me roughly sketch, how this could look like:
One of your company’s business concern is insufficient user productivity or lack of user satisfaction. From an IT perspective there might be several IT strategies and actions available to tackle these business concerns.
Wouldn’t it be good to have these IT strategies – in this case in particular the UX strategy - directly connected with the business strategies and concerns?
Imagine even a comparison of different IT strategies and UX options and their impact to your business concerns.
Think of a direct connection between the IT strategies you have identified with the necessary UX capabilities that need to be delivered by the IT environment. You would receive assistance to decide which new UX capabilities make the most sense for your case. Or you would learn about alternatives to modernize existing UX capabilities. Appropriate reference architectures could be described as well.
And recognize, so far we did not talk about any software product or installation process.
Now, think of moving to concrete software products. Dependent on the targeted strategy option(s) and the respective UX capabilities, you would now identify information about the required (SAP Fiori-related) software products or technologies and their UX features. Best practices or landscape deployment recommendations (example for SAP NetWeaver Gateway ) would be additional useful details to rate the impact on the concrete UX architecture in your enterprise.
After preparing the specific architectural decisions, you would even find connections to detailed information about required UX-related hardware & infrastructure resources, or the installation and configuration procedure for all needed SAP Fiori components in order to execute on the decisions and selections you have made before.
Having this structure in place, all the outlined information artifacts could be organized and related to each other. Furthermore a simplified access for different stakeholder could be provided:
Either directly (entry on a specific level), or by following the described path from top to down.
We are going to explain in more detail how the structure is applied to an UX (User Experience) Architecture or to a complete IT Landscape Architecture in upcoming blogs.
By using this information structure
As a result this will help customers in driving architectural decisions from the strategy level down to the physical installation of software products, and describing the impact of one level to the other.
In the last part of my blog I will add some information about the planned rollout strategy of content and tools covering those kind of structured information.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
7 | |
7 | |
7 | |
6 | |
6 | |
6 | |
5 | |
5 | |
5 | |
5 |