Skip to Content

One of the highlights of my month is attending the New York CTO Club, a group of CTOs that formed in the thick of the dot com era that has expanded to include almost every sort of CTO. We have been meeting monthly for more than six years. At the May meeting, a leading CTO came to present his analysis of the most important trends for IT for the next five years. In presenting his ideas, this CTO, who spoke confidentially to the group, made an interesting comment about modeling. He said that one of the frustrating things about model-driven techniques is that sometimes the models come out just as complicated as the programs they are trying to replace.

     

One of the key goals of modeling, whether it is to replace coding through a visual environment or to enable people to model and implement business processes (as in BPM), is to make things simpler and easier. If modeling achieves this goal, then developers can be more productive, more people can participate in crafting solutions, and making changes should be less difficult. For many people, drawing lines and graphics in a visual format instead of writing code is the beginning of simplicity. But, as the guest CTO points out, it is only the beginning. If you need to make a vastly complex model to get the job done, then you have visual spaghetti models instead of spaghetti code.

   

What then is the key to avoiding spaghetti in any form and achieving the goals of model-driven development and BPM?

   

In working on a book about the BPX role and on the Enterprise Services wiki, I’ve been talking to a lot of people about this and an answer seems to be coming into place. The design of services is the key. A couple of years ago, I worked with Kaj van de Loo on theEnterprise Services Design Guide, which defined a process and provided guidance for service enabling enterprise applications. For decades, SAP has been working on providing access to its functionality through RFCs and BAPIs, iDocs, and lately through enterprise services that are released through enhancement packages and documented in the ES wiki, which has descriptions and use cases for the ES bundles for services, and the ES Workplace, which has interface descriptions for ES Bundles and services related to business process components.

   

My thesis is that the only hope for simplicity in development or modeling is when most of the work of an application is done in services. When a set of services exists that does most of the work of an application, the modeling can be simple, invoking one service after another and passing information between them with minor transformations. But, if a lot of transformation of information has to take place in the model or the model has to, in effect, do work that should be done in a service, then you end up with spaghetti.

 

BPM and modeling work when services do the work

             

I think that the biggest implication of this position is that to get model-driven development or BPM right, the main event is designing and implementing a set of services that match the problem domain.  With such a set of services, the model does not need to be spaghetti and we may even make development simpler. But let’s dig deeper into what it means for a set of services to match a domain, what SAP is doing to attempt to make services match, and how a company should prepare to make the most of what is coming down the road.

 

To me the best match between services and a problem domain occurs when the services have all of the functionality to do the work you want to do. Then, you can focus on how to get what you want by invoking those services.  A bad match occurs when most of the work you need done cannot be performed by existing services.

     

For a while now, SAP has focused on visual development and modeling in a variety of ways. Visual Composer, Guided Procedures, the Composite Application Framework, all have been combined into the SAP NetWeaver Composition Environment. Project Galaxy functionality for  for business process modeling and business rules will become part of Introducing SAP NetWeaver Business Process Management (BPM).  But even if you could imagine the perfect composition and process modeling environment, it would be hamstrung without services that matched your problem domain

         

Community input increases probability of services matching the problem domain

Of course, it is impossible for every challenge to be perfectly matched by an existing collection of services. SAP’s approach to this challenge has been to supplement its internal service-enablement programs with outreach to the community. Through Industry Value Networks and the Enterprise Services Community, SAP customers and partners are able to express their challenges, the forces driving their businesses, and what they need from technology. (This happens in IVNs.) Then, once an opportunity for a needed collection of services has been identified, a group of SAP customers and partners can work with SAP in a collaborative process to design those services which will then be implemented by SAP. (This happens in the ES Community.) While most other vendors provide tools for creating services or focus on productized integrations for the most common scenarios, SAP is creating a broad and deep portfolio of implemented services with the help of its customers.

   

 
 To-do List for making the most of modeling, BPM, and enterprise services

In my second book for SAP, Enterprise Services Architecture, I suggested that there were three types of systems:

  • Stable systems for which the requirements did not change much at all.
  • Flexible systems for which the requirements changed every couple of years.
  • Dynamic systems for which the requirements changed constantly.

          

The biggest reward from a set of services will be to apply them to the dynamic systems, usually those systems that are close to the core value-creating processes of a business. If I were a CIO at a large SAP shop, I would be preparing to be able to accelerate innovation in the following ways:

   

  • First, I would make sure that my teams knew what services were available on the ES wiki and ES Workplace. If there were large gaps between those services and what I needed, I would use the ES Community to fill them in the long term.
  • Second, I would make sure that I created a development team that was expert in creating custom services to fill in gaps between what SAP has provided and the needs of my dynamic and flexible systems.
  • Third, I would try to build expertise in the SAP NetWeaver Composition Environment and Project Galaxy BPM functionality to see if these tools could accelerate development of solutions.

            

By doing this, you would know what services were available and you would be able to fill in gaps with custom services that did the work needed for each application so that the code or models the implemented the applications stayed as simple as possible.
 

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Richard Hirsch
    Dan,

    How do you suggest dealing with service-related requirements in “dynamic systems”? Are the requirements in such environments changing constantly as well?

    It is easy to change a Visual Composer UI to deal with new requirements. It is most costly (in terms of development effort) to change a service when new requirements arise. Yet, you suggest that the biggest reward of a healthy set of services will occur in an environment that is fluid.

    Dick

    (0) 
    1. Dan Woods Post author
      Dick,

      I think there are two approaches. One is that the most dynamic parts of the system are encapsulated in a service with a large functional scope that can then be the focus of rapid innovation. This is probably a good approach to start with.

      Once the problem area is understood a bit better, it is usually possible to break that large service into smaller components that can then be glued together via BPM or models without resulting in spaghetti.

      Let me know if my response gets to the heart of what you are asking.
      -Dan

      (0) 
  2. Matthias Haendly
    Hi Dan,

    point well taken, additionally the appearance of spaghetti models is also derived from the choosen level of detail you want to see. Tools allowing to choose the right abstraction level give you more choices, however the “fit” of the used enterprise services remains key.

    Regards, Matthias

    (0) 

Leave a Reply