The Standard

After a specific service or system is found to be needed to be ZO compliant its parts need to be analyzed for the following requirements, since these can influence the mechanisms that can be used to achieve ZO compliance. Before we list the most important requirements, let’s discuss one example in detail.

Impact of Business Requirements on a ZO Implementation – Detailed Example

Let’s assume that you run a website for hotel booking. As we will see, in the end, the decision to provide a service ZO-compliant is a business decision and the technical requirements are caused by the use case that shall be implemented.

Booking a Hotel – Use Case with Asynchronous Communication

Let’s assume, you will provide a page, where hotels are listed and customers will check for availability themselves on the hotels’ web pages.

1. Open the booking website
2. Enter filters (location / price / etc.)
3. Enter duration of stay (so that it can be handed over to hotel’s website)
4. System displays
   • Hotels fitting the filters
   • A function to open the selected hotel’s website to check for availability
5. Book

Required functions

All required functions of the booking web site can work asynchronously:

• List of hotels with static link, static picture, and static description

An asynchronous list is sufficient because of

• the low change rate of hotels and their features
• just linking to the hotels’ websites

Advantages

• Simple handling of a ZO implementation
• Availability can be easily achieved by having many instances of the site

Disadvantage

Iteration of step 4 is annoying, so customers will use a different website, which only hotels are shown that are available (leading to n steps, with frustration included):

Once your customers have found a web page that spares them the frustration, they will move to that vendor.

Booking a Hotel – Use Case with Synchronous Communication

Now, let’s assume, you will provide a page, where only hotels are listed that are available during the duration defined by the customer:

1. Open the booking web site
2. Enter filters (location / price / etc.)
3. Enter duration of stay
4. System displays hotels fitting the filters
5. Book

Required functions

All required functions of the booking web site need to work synchronously:

• List of hotels with static link, picture, and description
• A synchronous list plus a synchronization with the hotel is needed to ensure that only hotels are displayed that still have capacity for the entered time frame

Advantages

• No iteration – just 5 steps; no frustration due to selected hotels not being available;
• The pleasant experience will attract/keep users

Disadvantages

More complex handling of the implementation:

• Synchronous connection between hotels and websites, required to instantly update availability data of the hotel on a different company’s booking website
• Security needs to be ensured with access to data in another company’s system

Having seen how offering or not requiring synchronous communication, there are three main phases to apply this to your planning:

1. Assign ZO Capabilities to Landscape Entities
2. Understand Business Requirements Having an Impact on ZO Implementations
3. Assign Business Requirements to Each Application
4. Plan the Application and Platform Architecture Based on Business Requirements

Step 1: Assigning ZO Capabilities to Landscape Entities

In the following figure an example business process Order to Cash is visualized. What we can learn from this definition of a business process is that all layers of a platform will be involved and that there is a whole lot of applications involved. Given this just a very high-level consideration to get to a view of concrete parts, we need to refer to concrete examples shown in the next figures:

Figure: Hotel booking example

We can see several ZO aspects in this very simple picture:

• Some applications can be a ZO implementation – the customer portal system, booking web page, and development system –, while other functions are not.
• Also, to run a ZO implementation, the datacentre needs to be ZO compliant as well.
• You cannot assure the customer to be ZO compliant
• Having connections to the hotels to retrieve data from their systems will make things more complex (but more comfortable for the customer)

Step 2 – Understand Business Requirements Having an Impact on ZO Implementations

From the use case defined including its requirement to be ZO compliant, you can list the functions needed. For these functions, you now need to define the functions’ characteristics. The following tables list requirements as pairs which are harder or more easily to be achieved in a ZO environment:

Harder to Achieve in a ZO Environment	Easier to Achieve in a ZO Environment
Transactional Processing (always consistent) processing following the ACID paradigm of atomicity, consistency, isolation, durability. Example: Transactions are required in stock trading, where at any given point in time the ownership of an item needs to be clearly defined so that any change in the ownership is either fully done or not at all.	BASE handling of data only eventually providing consistency. This is easier to achieve and scales better. Example: BASE handling should be sufficient for results in search engines, since there is no exact result.
Synchronous communication based on request/response Example: Hotel booking web page ensuring availability of a set of hotels for entered time frame in its display	Asynchronous communication (with message allowing to be send without a direct response – see REST)
High Elasticity: Elasticity is needed in billing systems, which is used heavily once a month but idle most of the time	An application with low and predictable increase in usage not needing scalability
High Scalability: This is needed can be any application provided in the public internet, where user numbers can be very high and/or increase very quickly.	An application not needing scalability and elasticity could be a car manufacturer managing car dealers selling his cars – this number for any bigger company should raise or fall only slowly (duplication of sellers will not be a problem for a classical system)

These requirements can be needed independently of each other, which leads to a matrix of different sets of business requirement; they even can be different within one company. Therefore, it is important to clearly assign all requirements:

1. On the general ZO level assigning ZO capability to landscape entities (which even may be cross-vendor)
2. On the level of for business functions assign requirements influencing the ZO implementation (of course, being installed together may couple business functions that could otherwise be handled differently)

Step 3 – Assign Business Requirements to Each Application

As discussed, a map of business requirements is needed for all areas of the business process where you assign the requirements:

Business Requirements
Area/Function 1
☐	Is Part of ZO-Area
☐	Requires elasticity
☐	Requires high scalability (no predictable, constant system use)
☐	Transactional Processing (ACID) (non-transactional processing following the BASE paradigm not sufficient)
☐	Synchronous Communication needed (asynchronous Communication sufficient)
Iterate for Area/Functions 2 - n ...

Table: Combinations of platform-related business requirements.

Step 4: Plan the Application and Platform Architecture Based on Business Requirements

Once there is a map of the required functions, the architecture fulfilling these requirements can be planned. It is important to understand that most mechanisms or technical solutions have strengths and weaknesses, which need to be mapped to the requirements.

It’s also important to understand that the means to fulfil one business requirement may have a negative impact on others, which need to be mitigated. To illustrate the idea, here is a short list of such mechanisms to implement functions according to business requirements:

• High scalability:
  • Containers and NoSQL Databases help scaling.
  • CONS:
    • Containers introduce complexity
    • NoSQL Databases tend to only offer BASE; if transactional (ACID) processing is needed, additional solutions may be needed
• Transactional processing:
  • This is well understood in monolithic systems
  • CONS:
    • Doesn’t go together with high scalability
    • Some resilience mechanisms may not be ACID
• Synchronous communication:
  • CONS: Some resilience mechanisms may not be compatible with synchronous communication

So in the end, you will end-up creating a matrix of requirements and mechanisms to achieve them.