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.
Information Structure
There are four abstraction levels to provide different important views.
Level 0 - the Strategy View
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:
- What is the impact of your business and operating model to your IT architecture?
- How could business and IT needs for the architecture be aligned?
- What guiding principles for the IT architecture can be derived from the Business and IT strategy?
The deliverables of this level shall be IT specific (meaning concrete guiding principles for IT), but aligned with and driven by the business.
Level 1 - the Capability View
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:
- Which level of master data governance or business process governance has to be offered by the IT architecture within a certain business area?
- What kind of integration is required by the business for the used IT architectures (e.g. data integration between different applications, or user integration of internal and external user with different kind of applications)?
- How shall the landscape architecture for application capabilities like Talent Management or Customer & Accounts Management be designed within the enterprise (e.g. global vs. regional distribution, or headquarter vs. business unit governed)?
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.
Level 2 - the Software Product View
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:
- How does the architecture of a certain software product support the business and IT requirements of the enterprise?
- How can a certain software product (either on-premise or offered as a cloud service) be integrated with other software products (SAP or NON-SAP) in the company?
- What are the expected qualities of a software product to fit to the aimed deployment option in the system landscape? Think e.g. about version interoperability needs of centrally deployed products or between an on-premise and a cloud product.
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.
Level 3 - the Physical Installation View
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:
- Setting up software and hardware cluster to improve scalability and availability
- Scope and correct sequence of patching software components to keep functional consistency
- Supported operating or database systems for a planned software product installation
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.
Example
Think about the following little example. You have heard about SAP’s new user experience (UX) approach SAP Fiori:
- You will easily find a lot of information about SAP Fiori .
- You will find as well a lot of documents about features and the installation of SAP Fiori-related product components like SAPUI5 , SAP NetWeaver Gateway or SAP Fiori apps .
- Maybe you will find as well some additional useful information about the general SAP Fiori architecture .
- When reading all the different documents you might even get an idea, what business problem could be solved by installing the different product components.
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
- that organizes the relevant information artifacts along the particular stakeholder views,
- that simplifies setting the right focus from the expected architectural perspective, and
- that helps to provide an end-to-end picture from business to IT?
Let me roughly sketch, how this could look like:
UX Strategy (Level 0):
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.
UX Capabilities (Level 1):
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.
UX-related Software Products & Technologies (Level 2):
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.
UX Infrastructure (Level 3):
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.
Benefits
By using this information structure
- it is much easier now to organize existing or to create new information artifacts for the particular architectural decisions,
- it is simpler to provide access for stakeholders only to that kind of information that is relevant in this architectural context (pictured in the first diagram as individual entry point on different levels), and
- it is possible to connect different architectural perspectives by linking related information artifacts within the same level or even across different levels.
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.
- SAP Managed Tags:
1 Comment
