How an SAP Standards Architect helps SAP deliver business value

[Former Member]

Standards can have a big impact. Take, for example, the humble power plug. As a user, you never give the plug on a device a second thought. You just buy the product, plug it in and expect it to work. However, this only happens because the specs for the plug are a standard developed by a Standards Development Organization or SDO.

Application software is no different. Ideally you want to be able to plug software components together with little or no effort and with the confidence that they will just work. But, just as with the plug, this will only be really easy to do when the components you need to combine conform to a standard.

Right now, many application software standards exist that provide value, for example around Web services, but more standards are needed whose potential business value won’t be realized until they are created.

... which brings me to the topic for this blog - How an SAP Standards Architect helps SAP deliver business value.

SAP, as the largest application software company, recognizes that developing the "right" standards is important. It’s important to our customers and partners since they want to be able to realize the business value that can be generated by combining SAP with non-SAP solutions developed by other solution providers or in-house; as well as to SAP, since standards make SAP solutions more attractive as they can be more easily used by our customers in new ways at lower cost.

My role, as an SAP Standards Architect is to help make this happen. So let me expand on how standards deliver business value and the role the author plays, as an SAP Standards Architect, in helping SAP identify the standards that SAP develops and/or adopts.

How standards deliver business value

Standards for application software deliver business value in three main ways: they reduce IT costs; they help businesses work better and faster; and, they help businesses optimize their business networks.

Successful software standards lower IT costs primarily because they are implemented on platforms from multiple vendors. For example technology standards, such as Web services standards, reduce the cost of developing and implementing solutions that exchange data between heterogeneous systems. Similarly business standards, that define the content of the messages sent and received by a web service, lower costs by reducing or removing the need to map between different formats of business data.

The same technology and business standards are also a key enabler of Service Oriented Architecture. SOA - especially when combined with the ready-built enterprise services that SAP has developed - allow businesses to be more competitive since they can more easily build technology support in the form of composite applications, that enable better, more efficient and innovative methods of running a business.

Businesses also need to leverage their business network of suppliers, distributors, customers, and employees to compete effectively. These business networks are being used more and more to build tightly integrated collaborative processes that need to exchange information accurately and rapidly. Technology and business standards make it easier to create these types of networks by enabling better quality and faster flows of information. Without these standards building an effective business network can be very hard to do, especially networks involving smaller businesses, for reasons I explain in an Why using Web services for B2B is hard to do.

SAP uses the potential value that standards can provide as a guiding principle in working out where to focus its standards efforts. SAP does this to make sure that the resources it devotes to developing standards are used wisely and productively; and to identify opportunities to develop or adopt standards that provide value.

... which brings me to what an SAP Standards Architect actually does.

The main objective of an SAP Standards Architect is to help SAP focus on adopting, developing or leading standards that deliver business value. This requires that the SAP Standards Architect do three main things:

• Understand the standards "ecosystem" i.e. the environment in which standards are developed and used
• Develop SAP’s standards strategy i.e. work out what SAP should do around standards
• Execute SAP’s standards strategy i.e. carry out the activities required to make SAP’s standards strategy successful

Let’s look at each of these areas in more detail.

Understand the Standards Ecosystem

An ecosystem is defined as "the complex of a community of organisms and its environment functioning as an ecological unit". In SAP’s "Standards Ecosystem" three types of "organisms" exist:

• Standards Development Organizations (or SDOs). This includes technology standards organizations that focus on using technology more effectively; cross-industry business standards organizations that focus on defining the business information that is managed by the technology; plus literally thousands of vertical industry/business standards organizations that focus on developing business information and process standards that are specific to their industry
• Software Companies, such as SAP and its partners, that want to incorporate standards into solutions they sell, and
• Business Users, including both SAP and non-SAP users, and the people within them that want to use standards to help solve business problems.

Like any ecosystem the organisms within it interact synergistically. Computing software related SDOs usually rely on people that work for software companies to lead working groups and to develop the standards. These software companies sell products and solutions to businesses. These businesses, in turn, want solutions that use standards developed by SDOs to realize the business benefits they can bring.

This means that, as an SAP Standards Architect, you need to understand:

• The major SDOs, how they are organized and the processes they follow for developing standards
• The critical standards that key SDOs are working on and the relative business value those standards could provide to SAP, its customers and more widely in the IT industry
• The approach used by other software companies towards standards participation and adoption and how that could affect the way standards develop and evolve
• The way businesses could realize business value through the development and/or adoption of standards.

From an SAP perspective, the SAP Standards Architect also needs to understand: 

• In which SDO’s SAP participates and where SAP spends its resources
• The standards that SAP has adopted or plans to use in it’s products
• The architecture of SAP’s products and solutions to identify future opportunities where standards could deliver business value to SAP and it’s customers.

Developing SAP’s Standards Strategy

At a high level, SAP’s standards strategy is based on three principles. The first should be no surprise - standards must provide business value. But there are two more - broad adoption and implementation; and, minimizing the number of competing standards.

The importance of business value should be clear from what I’ve already written. It helps make sure that both SAP and its customers maximize the return on their investment of time and resources in developing, implementing and using standards.

A standard’s potential for broad adoption and implementation is important as, if only a few software companies implement a standard, then the hoped-for ability to easily combine software components will be significantly reduced.

Minimizing the number of competing standards is also important. Software companies, even large ones such as SAP, have finite resources to devote to implementing and supporting standards. If there are multiple competing standards, then there may be no resources available to implement a standard, or worse, effort may be wasted implementing a standard that does not get broad adoption. Either way, multiple competing standards are a barrier to adoption.

So given these principles and armed with knowledge of the "Standards Ecosystem", the next step is for the SAP Standards Architect to meet with the various parts of SAP to develop "standards strategies". This involves working with the platform teams, such as for SAP NetWeaver; the vertical industry and application teams, who develop the solutions that run on the platform; as well as the strategy teams that are working on SAP’s longer term goals and plans.

Each standards strategy contains:

• A prioritized list of standards that exist or could be developed that have the potential to offer significant business value to SAP and its customers
• A description of how and/or where those standards could or should be used in SAP solutions and potentially in solutions developed by SAP customers and partners
• For new standards, a description of how those standards should be developed and then adopted. For example, should the standard be started within an SDO, or perhaps initially in a smaller, nimbler group, that can later migrate to an SDO - see later for some examples; and
• An implementation plan that identifies roles, responsibilities, reporting, etc. for executing the strategy.

SAP’s value-based approach to developing standards strategies also has the interesting side-effect that SAP is very careful over deciding which standards to support and then implement in its products and solutions. It also means that, by following what standards SAP focuses on, others can use this information to work out which standards really matter for building applications.

Executing SAP’s Standards Strategy

A large part of the execution of a standards strategy occurs within SAP by development teams that help develop and/or implement and test solutions that incorporate standards.

For new standards, the strategy can be executed in different ways. Sometimes the SAP Standards Architect may represent SAP in a group in an SDO that is developing the standard. Alternatively an SAP developer may take this role with the SAP Standards Architect providing advice based on their experience in creating standards. Sometimes, a senior SAP representative may take senior board-level roles in SDOs in order to provide governance and to communicate SAP’s needs as well as those of SAP’s customers.

Sometimes though, developing a standard from scratch in a standards organization, although very open, has the disadvantage of being like designing a car by committee. It can take a very long time and the end result might not work very well.

A frequent alternative is for a small group of companies that have a real interest in developing a workable standard to get together to develop a first draft of a standard. Later, the group can expand to include more companies and eventually can submit the specification to an SDO.

One recent example of this is BPEL4People, which extends the BPEL process language for composing Web services to include processes that involve people. This was originally an SAP and IBM idea that later involved other organizations. In early 2008, it was submitted to an SDO, OASIS, to create a "Technical Committee" that takes the SAP and IBM work as its starting point.

Another example is the SAP Industry Value Network (IVN) for Banking, which involved a number of large banks and service providers in developing an overall architecture and the high-level service definitions required for banking software. The IVN Is now evolving into an independent SDO called the "Banking Industry Architecture Network" for evolution.

Once you get into the standardization activity itself, you need skills that go beyond a deep knowledge of the business or technology. A broad set of additional skills are required, that include:

• Leadership skills. These skills are especially important if you are chair of a standards working group. Sometimes it can feel like you’re herding cats as you have no direct authority over the other members of the group who work for other companies, often competitors. You have to rely on your project management skills and powers of persuasion to make sure the standards effort completes on time and the result is of high quality
• Technical writing skills. Particularly if you are an editor of a specification. You need to be able to clearly and unambiguously define how the standard works so that it can be implemented correctly
• Communication skills. You need to work closely with the other people working on the standard. You must also work with your developer teams to provide information on the direction of the standard and to get their feedback
• Diplomacy skills. You need to be a diplomat with good listening and persuasive skills to find the solutions that work well that everyone can accept, and finally
• Political skills. The participants in a standards development activity often work for competitors, so you need to understand what motivates their decisions on standards.

Conclusion

So to sum up, SAP takes a lot of care to invest in standards that deliver business value and that get broad adoption. SAP’s Standards Architects need to have a good understanding of technology, how businesses work and the business benefits standards can bring. They also need the ability to help SAP develop standards strategies that deliver business value to customers and partners. Finally a Standards Architect must be able to deliver on the strategies by working with partners and competitors inside standards organizations to deliver high quality standards specifications.