- What Is a Solution Vision?
- SAP System Landscape Design and Planning Approaches
- Capturing Your mySAP Solution Vision
- Outsourcing—Another Method of Achieving Your Solution Vision
- Tools and Techniques
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
SAP System Landscape Design and Planning Approaches
Remember, a system landscape exists for each mySAP solution—if you deploy R/3, APO, CRM, and PLM, you will in effect be creating four different SAP system landscapes, one for each product. The focus in this and the following few sections, though, is on what one of these system landscapes looks like from a design and planning perspective, for example R/3 alone or APO alone.
In the most general form, an SAP system landscape consists of SAP instances (installations of the SAP database and application software) and SAP servers. In the Microsoft world of SAP implementations, there is a one-to-one correlation between instances and servers nearly all the time. That is, the Development instance resides on a dedicated Development server, the Test instance resides on a dedicated Test server, and so on. In the world of UNIX implementations, though, multiple instances can be often found on a single "larger" server. For example, both Development and Test instances can reside on a single server. And multiple application instances can be installed on a single server as well.
Until last year's release of SAP's Multiple Components, One Database (MCOD) initiative, there was a one-to-one correlation between instances and database systems, too, regardless of the Operating System platform. MCOD is beginning to change this, such that a single "larger" database can be leveraged for multiple instances. However, an important difference between MCOD and multiple instances/one server exists—MCOD ties the same type of databases within different SAP system landscapes together. With MCOD, all Development databases used by your R/3, SRM, CRM, and Workplace implementations can be one and the same. Similarly, all Test databases across R/3, SRM, CRM, and Workplace can be bundled together, too, as illustrated in Figure 3.3. Note, however, that in many cases SAP AG frowns on mixing OLTP and OLAP systems, or combining different databases within the same system landscape. In that regard, forcing an MCOD database server to host your R/3 system's Development and Test databases would therefore be unsupported and contrary to best practices.
)
Figure
3.3 A properly architected sample MCOD deployment is displayed for a typical
mySAP enterprise consisting of R/3, CRM, SRM, and Workplace.
As we move forward with our basic understanding of SAP system landscapes, and seek to understand how your SAP solution vision impacts and is impacted by your landscape decisions, my hope is to achieve the following:
Note the relative importance and relationship of technology perspectives to our solution vision
Understand why each system landscape is important to fulfilling our vision
Note how the presence or absence of a particular system within a landscape impacts the other systems and ultimately the overall solution vision
All these design and planning approaches I cover tend to come into play in one manner or another across all mySAP implementations. It's how they are weighted or addressed that makes one system landscape different from the next.
Simplifying Your SAP System Landscape
After spending time with hundreds of customers and SAP implementations, I think it is safe to say that when all things are equal, the desire to simplify emerges as an important driver. Simplification takes many forms, too. In the case of the SAP system landscape and how it fulfills our SAP solution vision, the desire to simplify manifests itself in any number of ways:
First, the pure number of instances will be reduced to the fewest necessary to get the job done "right" for a particular company. An organization focused on simplifying administrative, change management, systems management, operations, and other tasks will deploy a three-system or even a two-system landscape, whereas similar organizations without the same simplification goals can deploy more. There are trade-offs, of course. A system landscape without a dedicated test instance will, for example, be forced to perform testing in the same system used for development. Because of these kinds of limitations, simplification achieved through instance reductions is not as common as it has been in the past.
-
Instead, a more popular approach to simplification seeks to reduce the number of physical servers in a particular system landscape, by installing multiple instances on a single server. Consolidation of instances is becoming quite common in SAP customer environments today, as displayed in Figure 3.4.
)
Figure
3.4 Multiple SAP instances can be installed and configured on a single physical
server, oftentimes reducing both acquisition and systems management costs down
the road.
Similarly, deploying a shared disk subsystem and tape backup/restore solution also simplifies a very complex piece of the SAP Solution Stack. This is why my colleagues and I have spent so much time in the last two years designing and implementing Storage Area Networks, or SANs—they provide outstanding performance while simultaneously reducing system landscape complexity and allowing expensive resources like enterprise tape libraries to be shared between systems.
Another customer of mine shared with me why they went with the WebGUI as opposed to the classic SAPGUI approach to system accessibility—to simplify desktop support and maintenance requirements.
Companies that value simplification will also standardize on a particular solution stack option or approach, too, as this simplifies support and maintenance, and minimizes the need for a variety of onsite/reserved spare parts, the time spent in change management activities, and more.
Although simplification tends to work in one direction by encouraging a "do more with less" philosophy, our next topic goes the other route in that it purposefully introduces complexity and differences between various systems within a system landscape—high availability.
High Availability and the SAP System Landscape
When it comes to high availability, many technology professionals automatically think about what it means to improve the availability of a particular system or hardware component—thoughts of basic HA offerings like clustering or redundancy come to mind. With regard to the broader topic of how your solution vision impacts your SAP system landscape, though, high availability equates to the following:
Business-driven requirements—HA offerings and approaches are normally implemented to satisfy specific business-oriented needs, and therefore form an integral part of your overall SAP solution vision.
Complexity—HA complicates the SAP system landscape, as HA offerings and approaches tend to only really exist or apply to the Production system and at minimum (hopefully!) another similarly configured system within the landscape.
Increased support needs—Because HA offerings are inherently complex, a very real need exists to prepare your SAP support organization in how to install it, update it, manage it, and troubleshoot HA issues.
To read more about how business requirements relate to high availability, see "Availability Planning—Documenting Requirements and Key Drivers," p. 167 in Chapter 6.
Disaster Recovery Considerations
All companies implement a method of addressing Disaster Recovery (DR), whether or not they actually realize it. Even companies that do not add a dedicated DR system to their system landscape address disaster recovery. That is, their de facto disaster recovery plan simply reflects the challenges and timeframes surrounding rebuilding their SAP system from scratch, restoring from their latest tape backup, and imposing upon their end users to manually rekey any new business transactions lost between the last successful tape backup and the point at which the disaster occurred. This doesn't sound like much of a "plan," of course, but it does represent a baseline against which all other disaster recovery approaches and solutions can be weighed.
A host of DR approaches are discussed throughout Chapter 6, from those involving disk subsystem data replication solutions, to various clustering solutions, to database and mySAP-specific tactics. But when it comes to sifting the potential layout of your SAP system landscape through your solution vision, two general approaches fall out:
Creating and maintaining a dedicated Disaster Recovery system within your overall system landscape.
Outsourcing your Disaster Recovery system to an outsourcing provider.
Both approaches are valid, and the first is more traditional. But I believe that the time and expense related to setting up, configuring, keeping current, and managing your own DR system explains the recent increase in outsourcing I've seen over the last two years.
To review some of the tasks and considerations inherent to addressing DR internally as opposed to outsourcing it, see "SAP General Availability and DR Best Practices," p. 207 in Chapter 6.
Companies that outsource the DR component of their SAP system landscape help to preserve their data, and access to this data, in that the outsourcer operates a completely independent data center, typically in a very different geographic location. For smaller and mid-size companies with only a single data center, the expense relief is tremendous. On the other hand, if the DR solution is maintained "in-house," so to speak, it will need to be housed in a separate facility. This alone is sure to drive complexity, cost, and even the architecture and makeup of both the SAP system landscape and its individual systems.
Addressing Training Requirements
The SAP system landscape is directly impacted by the potential need to train SAP end users as well as the system's developers and technical support staff. Three different systems come into play, as illustrated in Figure 3.5:
A dedicated Training system is often implemented to assist in teaching users new to a particular mySAP component how to actually use the system. This amounts to business-process training as well as SAP user interface training (an excellent alternative to creating multiple training clients on the Test system, which is busy fulfilling integration responsibilities prior to Go-Live—the exact time when end users need to be trained!). To provide the most value to its students, the Training system needs to be an exact copy of Production.
A dedicated Technical Sandbox system is extremely useful in helping the SAP Technical Support Organization (SAP TSO) get up to speed on the entire SAP Solution Stack, especially with regard to new components and complex HA offerings (rather than attempting to get time on other systems for what could amount to crash-and-burn testing).
A dedicated Business Sandbox or Development Sandbox system allows developers unfamiliar with a particular mySAP component, or faced with integrating multiple components and other legacy systems, the opportunity to do so in a pure testing environment (rather than the real Development system).
)
Figure
3.5 These SAP training systems support the different needs of different
organizations, from end users, to developers and programmers, to technical implementation
specialists.
For details as to how the SAP system landscape satisfies the training needs of both the SAP Technical Support Organization and the production system's end users, see "Training and the Role of the SAP System Landscape," p. 314 in Chapter 9.
It can represent quite a challenge for the "customers" of one of these training systems to convince everyone that such a system is truly required. In my own experience, I have seen the lack of a Technical Sandbox really hurt an organization in terms of downtime due to botched infrastructure upgrades and changes to DR processes.
Another colleague of mine has more than once had to strongly push for the adoption of a Training system, too. Such a system allows for extensive informal user testing and practice outside of formally delivered training. He believes that this extra level of hands-on self-directed training is critical because your end-user community is best positioned of all groups to find business-process operational errors and limitations. And of course it is desirable to correct these issues well before Go-Live. But a consultant or even a senior super user is typically not positioned to push the adoption and use of a dedicated Training system. More often than not, it takes the SAP Steering Committee, the project's experienced management team, and the prodding of a knowledgeable SAP Solution Architect to do so. I cannot stress this enough—the risk is huge, in that you do not want to find out too late that not every business scenario works as it did during integration testing (for example, all types of contracts, all types of material movements, all kinds of accounting entries, and so on).
The Performance-Driven System Landscape
When it comes to evaluating your solution vision against the layout of your SAP system landscape, it is important to ensure that the performance of the systems meets the needs of their different end-user communities. Most of the time, of course, the focus is on designing, installing, and configuring a well-performing Production system. Performance considerations usually relate back to what an end user will experience while on the system, including
Business transaction response times, or how long it takes to refresh your SAPGUI after pressing the Enter key, for example.
How quickly a background or "batch" job will execute, otherwise known as throughput.
How quickly a report or other query will make it through the system and actually be printed, sometimes called latency.
To read more about verifying that a Production system can meet performance expectations, see "Key SAP Stress-Testing Considerations," p. 580 in Chapter 16.
However, these same performance considerations apply to all of the other systems within the SAP system landscape, too. The Development system, for example, needs to exhibit excellent performance even while 25 or 50 or more developers are banging away at keyboards trying to build your custom mySAP solution. Similarly, your Test system needs to provide the performance necessary to get through integration testing. Even the Training system needs to provide adequate user response times so as to make the actual training experience more than something to be avoided.
High-performance considerations cover the gamut, touching every facet of every system within the landscape. This means that everything—from the performance of the network connecting each system, to each server's CPU, RAM, and disk configuration, to each system's OS, database, and mySAP component—must be addressed. Starting off on the right foot (with properly sized and configured hardware and software elements) is paramount, of course, but tuning all these solution stack pieces to create a cohesive well-running machine is just as important to achieving excellent performance. Like the weakest link in a chain, a single underperforming solution component will only throttle back the maximum performance otherwise obtainable from your system.
Driving Scalability into Your System Landscape
The need for scalability, like high availability and excellent performance, is addressed primarily through the sizing process. Scalability does not pay off up front in terms of improved system availability or better user response times, though. Rather, scalability is all about paying for "headroom" in your system, headroom that is not actually needed at present but might be required in the near future. In other words, scalability addresses future planned and unplanned growth in your system.
This growth can manifest itself in a number of ways. In my experience in the real world, I have seen the results of unplanned growth hurt companies where scalability was never addressed, as in the following cases:
The number of end users increased at one of my new accounts, not due to more hiring than was anticipated when their mySAP.com solution was crafted, but because they unexpectedly acquired their competitor and doubled in size. We had six months to project the delta needed in terms of database and application server processing power and RAM requirements, followed by stress-testing the new design and finally implementing it.
More than one of my customers' databases grew so fast that they outstripped the results of their comprehensive three-year database sizing methodology in the first year! In most cases, the system we put in place for these customers was scalable—more disk drives could be added, smaller drives could be swapped with larger ones, and so on. In three cases in particular, though, the database growth was so explosive that a whole new disk subsystem platform needed to be brought in, and the recently acquired current platform retired (or redeployed) years earlier than expected.
When databases grow quickly, the tape backup/restore solution implemented often grows less effective as well. I have seen this most often in relatively small SAP implementations, where an initial investment in tape backup technology needed to be tossed in favor of tape solutions that backed up more data per tape cartridge, and did so fast enough to not exceed the customer's backup window (time allotted to perform a backup, which usually equates to planned downtime in the case of offline full backups).
It's been a while, but I also had a customer outgrow their network, too. Today, with switched networks and Gigabit Ethernet providing more than adequate bandwidth to every mySAP.com server component, and cheap 10- and 100-Megabit Ethernet prevalent across end-user workstations, there's no excuse for lacking network scalability.
Outstripping the capabilities of your current system such that a new platform is needed probably represents a worst-case scenario. Not only does the current Production component need to be replaced, but to support sound change control principles, so does the same component in your Test, Staging, and/or Technical Sandbox environments.
This is why hardware and software vendors tout things like "highly scalable system architectures," "enterprise versions" of particular Operating Systems and Database Systems, and so on—though not necessarily needed up front, the headroom that these approaches provide helps an organization feel more comfortable if they wind up growing faster than they expected. And hardware vendors in particular can position their SAP clients for improved scalability by practicing the following:
Specify server platforms that allow additional CPUs and RAM to be added as needed. In other words, avoid "maxing out" the box.
Alternatively, design SAP solutions such that they take advantage of SAP's support for horizontal scalability. This is one of my favorite approaches when it comes to SAP Application, Web AS, J2EE middleware, and ITS servers—I prefer to max them out with regard to processors, with the understanding that an incremental number of servers can be added at any time should the environment grow to require it (interestingly, although SAP has successfully tested a system running more than 160 application servers, it is rare to find customer implementations with more than 10 or 12).
Architect a solution for the appropriate level of vertical scalability. In other words, if a two-tier "Central System" (where all SAP software components execute on the same physical server) approach to sizing meets today's requirements, perhaps a three-tier solution will provide for unknown scalability requirements. In a three-tiered architecture, one database server and multiple application servers are configured as a single system image.
Architect a highly scalable database platform. As my real-world examples earlier in this list illustrate, this tends to be where a lack of scalability causes the most problems.
Hardware and software vendors alike spend a great deal of time "proving" how scalable their offerings are. As a first step, I suggest that benchmarks, customer references/feedback, and the results of tests published through white papers and other technical documents be reviewed by prospective mySAP customers. I also suggest that you begin considering new approaches to scalability. For example, HP's iCOD offering touts "capacity on demand." When a customer buys a server, for instance, it is fully populated with CPUs. The customer pays for only what is needed in the near term, however. Later, if it is determined that more processing power is required, the customer takes advantage of the in-place processors by merely applying for a license; no intrusive field upgrade or service call is required and therefore the need for planned downtime is drastically reduced.
The TCO-Driven System Landscape
More than anything else, Total Cost of Ownership (TCO) drives what a solution vision actually looks like at the end of the day, when a mySAP solution is implemented and really being used. Discussions on TCO might instead be labeled Return on Investment (ROI), or might fall under the heading of investment protection. Regardless, a focus on lowering TCO seeks to find less expensive solution-stack alternatives that still meet the needs of the business.
To read more about the relationship between TCO and your SAP solution vision, see "How the SAP Solution Vision Drives TCO," p. 127 in Chapter 5.
When all other things are equal, the following points apply from a hardware perspective:
A hardware vendor's use of common components like CPUs and memory boards allows flexible sharing of resources between different SAP system landscapes and in some cases hardware platforms, too.
Similarly, common disk drive form factors reduce cost of ownership by increasing reusability.
Support for hot-pluggable and/or hot-add hardware components eliminates or worst-case minimizes downtime (can include hard drives, tape drives, power supplies, fans, and even RAM and processors).
Support for redundant components, like power supplies, disk drives, fans, and so on, also eliminates or minimizes downtime.
The ability to run mixed-speed CPUs or RAM in a particular platform protects that investment—CPUs and RAM do not have to be tossed aside when additional processing power or memory is required.
Outsourcing your entire SAP infrastructure/operations team is another potential method of reducing TCO. In fact, outsourcing can represent the biggest potential TCO factor that a company will consider. At this level, though, outsourcing becomes more of a strategic business solution that impacts a lot more than simply TCO. True, outsourcing can cut labor costs by 50%, and enhance flexibility of a technical support organization to easily change as business requirements change, but there are drawbacks and disadvantages as well (discussed later in this chapter).
Another solution vision approach that impacts the SAP system landscape from both a configuration and TCO perspective is the use of an Application Service Provider (ASP). ASPs can drive lower TCO by virtue of their application-specific expertise, above and beyond that provided by in-house staff and traditional outsourcing providers. For example:
An ASP can offer a preconfigured solution stack for the particular mySAP solution you want to implement. This is one reason why they look so good from a TCO perspective—design, deployment, manageability, operations, and other cost factors are substantially reduced due to a high level of both standardization and core competencies in the services they provide.
ASPs were more or less born out of the dot-com era, and by virtue of this, their data centers enjoy the benefit of fat redundant pipes to the Internet. Thus, mySAP.com applications are well positioned to take advantage of this flexible and powerful accessibility option.
ASPs offer interesting financing alternatives, in that they partner with various SAP technology partners to make leasing, pay-as-you-go, and other payment methods available.
The ASP provider market shrank over the last few years. The mySAP-focused companies that weathered these hard times seem even better prepared and well-positioned to host SAP solutions, however.
Security Considerations
I know of no company that does not envision protecting its corporate computing assets. From a solution-stack security perspective, not all software vendors are created equal, however. Oracle touts its unbreakable database, UNIX vendors tout the robust security features of their operating environments, and so on. In my eyes, security features are very important, but good security is more often about managing and testing changes to a solution stack, by carefully identifying security holes and other weaknesses in new solution stack components before these components ever find themselves in Production.
However, companies that embrace and act upon the idea of protecting computing assets will prove to be better partners in the long run. This is why I believe that Oracle's focus on security will pay big dividends in terms of slowing the adoption of competing databases. And it is why I believe that the Trusted PC joint Intel, AMD, and Microsoft vision (once labeled by Microsoft as Palladium, and now referred to as the "next-generation secure computing base for Windows") will prove fruitful as well. Its goal is to build security into servers and PCs at a microprocessor level. New initiatives coming out of the Trusted Computing Platform Alliance promise to better secure our processing platforms, ensuring that only authorized applications and program executables can ever be executed by the system, and that all data housed on the system is encrypted so that it is useless to others. To this end, Microsoft considers Trusted PC a significant part of its Trustworthy Computing strategy—we should see something commercially available in this regard by 2004 that applies to server as well as desktop and other computing platforms.
Manageability Considerations
No customers of mine have ever started their initial SAP implementation planning discussions with me by saying:
By the time Go-Live looms just over the horizon, though, every single one of them—without exception—has indicated a growing concern for manageability. Sure, it's there on the project plan, and any number of products can be used to support managing your mySAP environment. But the whole field of manageability is more complex and more work than you would imagine. Consider the following:
Each layer in the SAP Solution Stack must be managed; the risk of not keeping an eye on a particular layer or solution component affects the uptime of the entire system.
Because each layer is so different from the others, it's nearly impossible to find a single management product that can actually monitor and report on more than a few layers, much less the entire stack.
Therefore, the next best thing becomes trying to find a product that can at least interoperate successfully with other products.
At the end of the day, three, four, or even more tools and utilities must ultimately be fused together to provide a holistic view of a mySAP solution stack. This is challenging, to say the least!
To learn exactly how challenging piecing together a management approach can be, see "Systems Management Techniques for SAP," p. 511 in Chapter 14.
Because of the challenges inherent to managing hardware and software products from a lot of different solution stack vendors, some of my customers have purposely chosen less than "best-of-breed" products for their SAP solutions, so as to minimize the number of software partners involved. Or they have decided to reduce the number of partners and vendors altogether by selecting one of the big enterprise hardware/services vendors. The obvious partners are clear—HP, IBM, and Sun. For example, if you go with HP and choose to implement an rp8400-based server platform with an HP StorageWorks SAN, running HP-UX 11i, and managed by HP OpenView, the challenges inherent to managing four different vendors' products just dropped tremendously. Similar arguments could be made for going with an IBM or Sun solution stack, too—IBM even throws a couple of databases into the mix.
The System Landscape and Accessibility
The last area I want to cover with regard to solution vision and the SAP system landscape is accessibility. Many companies over the last three or four years have started with a vision of dumping all application-specific interfaces in favor of browser-enabled solutions, so as to ease the burdens and costs associated with desktop/laptop management while opening up new accessibility approaches like hand-helds and other wireless devices. SAP has supported that vision since 1996, with the advent of Internet connectivity in R/3 3.1G. But only in the last few years have I really seen this take off.
SAP AG offers quite a few accessibility options today when it comes to mySAP solutions. The classic SAPGUI and its revamped and more capable EnjoySAP SAPGUI represent one end of the spectrum. This approach is safe, very mainstream, and very easy to implement. And the SAPGUI we have today is extremely comprehensive, supporting all mySAP components through a single interface, which is unlike the approach a few years ago where each so-called "New Dimension" product like BW or APO required its own GUI. But the SAPGUI still represents a typical application-specific approach to accessibility; each end user installs the client on their desktop or laptop, or runs the SAPGUI from a network share, and off they go.
Other accessibility approaches are available, however, as you see in Figure 3.6. The original WebGUI, for example, is based on HTML and provides connectivity via Microsoft's Internet Explorer and so on. And a more recent addition, the JavaGUI, allows native Java-based access to SAP. Both of these approaches fulfill an Internet-based approach to connectivity, and subsequently simplify the desktop (assuming Internet connectivity is a standard desktop offering at your particular company, of course).
)
Figure
3.6 Access to mySAP solutions is quite varied today, ranging from classic
and updated SAPGUI options to newer Web-enabled versions.