Have you ever tried to promote the topic of UX to management in your company, but failed? Do you think that it is difficult to explain the benefit of UX improvements? Do you have difficulties in relating UX to business strategies and goals? Do you think it is difficult to build an architecture for UX?
If your answer to any of these questions is yes, this blog will help you.
One key issue is that the people around us speak different languages and have different goals and concerns. Think of how different the goals are for a more business-oriented person compared to a technician. Or think about the typical concerns of a CEO vs. the concerns of a business end user.
If you want to be able to answer the questions listed above with no, you need to speak the same language as other people in your company, consider their goals and understand their concerns and viewpoints. Enterprise Architecture can help us here. But let’s start from the beginning.
What is Enterprise Architecture?
Over a year ago, Enterprise Architecture (EA) crossed my path. For those of you who are not familiar with Enterprise Architecture, the following quote might provide a good introduction:
Enterprise architecture (EA) is "a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a holistic approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes."
From the EA Perspectives White Paper of the Federation of Enterprise Architecture Professional Organizations
The terms I have marked in green are particularly interesting for me, and they map a lot with the things we also need in our UX improvement projects.
If you are new to EA and start digging deeper, please don’t be irritated by the endless amount of available methods, documentations and rules – just give Enterprise Architecture a chance. Actually, it took me a while to connect the provided ideas, structures and methods with my own environment and topics too. But eventually it all made sense.
You can maybe compare it to Microsoft’s Excel. Even if you are only use a small portion of its overall scope, it can already be very beneficial to you.
What is the connection between User Experience and Enterprise Architecture?
If you are familiar with my previous blogs and videos, you will know that I like to push the Adopt-Adapt-Develop options. We can start at this point again and think of the different high level milestones that need to be completed. Even at a high level, this provides an interesting insight.
The three options are of course embedded in an overall project with its milestones. Again, this all is sketched at a high level, and I realize that there are many more milestones and steps to be completed. The interesting point however is where Enterprise Architecture can help me. I imagine that an enterprise architect would probably say “everywhere”. As I mentioned before, I would like to start using just a smaller portion of the EA cake. I have therefore added red dots at places where I immediately see potential benefit from EA-based activities. Isn’t that impressive enough to take a closer look at Enterprise Architecture?
What are the challenges in building an architecture?
Thinking about building the architecture of an enterprise, we would usually expect this to start from business strategies, defining the capabilities that IT has to provide to support business needs, identifying the concrete software products or services to realize these capabilities and finally determining the required physical installation of the software.
In practice however, my observations have led me to see this differently. Many activities in IT are still driven by technology decisions. The business context is connected afterwards. This means that architectures are often built from the bottom up to the top.
What could the reason for this be? Actually there are many reasons, such as:
- There is no enterprise architect involved in the project
- There are no business stakeholders deeply involved in the project
- There is a lot of technical information available
- There is little information available about IT capabilities and their connection to strategy goals
The last two points probably explain why projects are technology driven. If there is no adequate information available, people build their decisions based on what they have, even if this is a rather illogical sequence.
If you are interested in learning more about the different challenges, I recommend the blog “Enterprise Architecture Tangible…(Part 1: Challenges & Goals)” by dirk.anthony.
Which part of Enterprise Architecture is of most value for me?
This is obviously a very provocative question, since I assume that there are many different opinions out there in the EA community. I therefore do not want to start a discussion now on what is important and what is not.
I would just like to give you the opportunity to benefit from my observations to start at a certain point, even without being the EA expert, yet. In the team I’m working in, we created a little information framework that considers Enterprise Architecture-related thinking and practices. The core of this information framework is a four level view on IT architectures providing an abstraction on “Strategies”, “IT Capabilities”, “Software Products” as well as the “Physical Installation”.
At the beginning of the blog, I mentioned the different languages that people around us are speaking. I also mentioned their different goals, concerns and viewpoints. The picture above provides just a few examples of types of information that are of interest for these different people at the different levels. We can assign these different people (roles) to the levels and will then have the following picture.
Obviously, in a real project you might have additional roles. But you will notice that there are roles who primarily focus on one level. The CEO might focus on strategies for example, especially the business strategies. The software products that have to be installed are not normally of any interest to the CEO.
You will also notice other roles that work between two levels. The project lead needs to understand the strategies for example, but also needs to translate this into real requirements and IT capabilities towards IT.
While most of the roles traditionally focus on a horizontal level, there is finally the role of an enterprise architect, who is probably not interested in all the horizontal details but very interested in understanding the vertical connection.
If you are interested in learning more about the information framework and level, I recommend Dirk’s blog “Enterprise Architecture Tangible…(Part 2: A Solution Approach)”.
What pieces are still missing?
All of the roles we saw in the previous picture are searching for specific information. As mentioned earlier, there is already a large amount of information available for the “software products” and “physical installation” levels. As an example, you would easily find product brochures, product descriptions, function descriptions or installation and upgrade guidelines. This might explain why many projects are driven by these levels and the available information.
As indicated in red in the graphic above, what is still missing is information about the “strategies” and “IT capabilities” levels. We need this to answer questions like:
- What are examples of strategic goals for UX?
- Which typical IT capabilities influence UX?
- Which capabilities are connected to which strategic goals?
It would be obviously also be helpful to have a chance to understand the relations between a specific strategy goal, the therefore required capabilities and their related products and features. This would enable us to connect the various architectural perspectives with each other in order to provide a consistent comprehensive picture.
In addition to helping us to promote our interests to others, this would also enable us to create an architecture in the correct sequence, from top to bottom.
Which pieces could be provided in the future?
It therefore becomes clear that we need to provide the people out there with the specific information pieces they need at their level and enable them to talk with people from other levels.
Our idea is to create this information in the future and to provide it via the SAP UX Explorer, which implies that the SAP UX Explorer is going to grow, probably beyond UX.
The graphic below indicates the different information types that we plan to provide.
Let me briefly explain the different types of information, which we separate into methods and assets.
| Information | Benefits | Examples |
|---|---|---|
| How to set up a custom UX strategy (Method) This piece of information is already available and will be further improved where needed. |
| |
Strategic goals of UX (Assets) During the course of the next few weeks, we will start here with an initial list of strategy goals that we think are common in the context of user experience improvements. |
|
|
UX Capabilities (Assets) We are also going to start with an initial list here during the course of the next few weeks. |
|
|
UX concerns (Assets) We plan to generate a library of typical UX concerns with a description of related source and target architectures (architecture viewpoints). We are currently updating the information we already have in the UX Explorer and will publish the updates during the course of the next few weeks too. |
|
|
Architecture Viewpoints (Assets) As mentioned with the UX concerns, we plan to generate views of specific source and target architectures. We will call these viewpoints, again in alignment with Enterprise Architecture. |
|
|
Architecture Practices (Method) Finally, we would like to enable you to generate your own viewpoints that address your customer specific concerns. This material might not be available until 2016 however. |
Where this might lead us to – a little vision not so far away
Imagine a place where you could review typical UX strategy goals or UX capabilities. Think of a place where you can search for typical UX concerns, so that you can find those that correspond most closely to your own. These UX concerns would include descriptions and guidance, and would be connected to typical UX architectures.
Or imagine a tool where you can select from various business strategies. You could select “Increase employee satisfaction” for example, and the tool would then list you a couple of IT and UX strategy goals connected to the business strategy. Maybe something like this:
- Improve working environment of employees beyond software
- Prioritize user satisfaction over costs
- Provide applications suitable to users (e.g. focusing their roles and tasks)
- Provide access to software where needed
- Provide a simple working environment
- Provide coherent user experience within user role or roles
- Improve user experience for power users
- Improve user experience for visually impaired users
- Provide single point of entry
- Provide consistent navigation for one user
If you were to select some of these IT/UX strategy goals, the tool could then probably list you all the related capabilities. And finally the tool could provide you with all the SAP products and features which are connected to these capabilities.
This might sound like wishful thinking, but I believe that the current content in the SAP UX Explorer proves that this is already possible. If you look into role-based access for example and scroll down to the “Explorer Relations” section, you will find a relation type called “Is supported by the following UI technologies”. Role-based access is the UX capability. The Explorer already provides you with the relation to the corresponding SAP products/features. We obviously need to tweak this a bit in order to reflect the right wording. Role-based access is currently positioned as a concept and needs to be changed to be a UX capability. And of course, we also need to add many more UX capabilities.
This will take some time. But I am confident that we will make it and that your feedback will improve it further. This is just the next stage of a longer journey.
If you want to be part of this journey and be kept up-to-date about upcoming enhancements, just follow me on Twitter or register for the SAP UX Explorer Newsletter.
Looking forward to see what the coming months will bring.
-JJ
PS: If you are an ASUG member, you might be interested in the recording of a recent webinar called Enterprise Architecture under the light of UX (login required).
- SAP Managed Tags:
3 Comments