I was in Silicon Valley last week, and caught part of a demo of Composition on Grails. This is a project within SAP built on top of SAP NetWeaver Composition Environment.
I decided to change my plans, and had lunch with Will Gardella and his team. (Will gave the demo, and his team is building Composition on Grails within SAP.)
I’d never considered SAP or its business very interesting, because I misunderstood what SAP actually does. Though I very happily left the world of the Enterprise (twice, first as a system adminstrator and then as a consultant who wrote and maintained business software), and though SAP’s choice of technologies (ABAP, Java, WSDL, WS-*, shared-everything) are different from my preferences, it took just a few minutes for Will’s demo to convince me that I had overlooked something very interesting.
At lunch, I said something like “I’m sure you see a lot of business processes in plenty of industries, where they’re different and where they’re similar.” Someone responded that SAP finds that hidden knowledge and extracts the similarites and any customization points.
Suppose I write software to model an ice cream booth. I’ll model with products, with customers, with a menu, with a payment system, and so on. The result will be a sufficiently accurate model of the business of selling ice cream and an example of a food-service business.
My next task is to model a high-end restaurant. There will be similarities to the ice cream stand — inventory, menus, payment — but there will be differences, including tables and zones, extra wait staff, cooks, and more.
My final task is to model a catering service. By the time I finish this model, I probably know enough to generalize about how all food service businesses work. The result won’t necessarily be complete or perfect for any of those three businesses, but it’s a place to start. It’s the same principle as once, twice, refactor, applied to business process modeling rather than source code.
There’s an advantage to having an almost-ready starting point if you want to create software. That’s why we use frameworks and libraries and rich APIs. That’s why there’s plenty of money in bespoke software.
Though there’s plenty of money in customizing this software, part of the value proposition to adopting business process software is the integration of other software. If I can make use of other well-understood business processes such as accounting and payroll and employee management, I can provide very useful software to all three businesses. That is, if you install SAP’s CRM, you can integrate it with their ERP, and their dashboards and portals, and so on.
All of this software has to interoperate. Historically, this was through a wad of code in shared libraries that SAP calls BAPI. That still works (remember, enterprise software lasts a long time between upgrades, much to the chagrin of developers and vendors), but there’s also a SOA system in recent versions.
Go ahead and wince at the thought of debugging SOAP and WSDL. I’ve done it myself. Note the past tense; I’ll personally use REST and APP and similar systems myself the next time I need that kind of interoperability, but this architecture can work.
It’s also the opportunity for Composition on Grails.
SOA and WS-* are big. They’re really big. They’re complex, and it’s difficult to manage that complexity with simplicity. Choosing SOA and WS-* bounds the scope of any potential solutions to a specific minimum level of complexity.
If you need to solve really big problems, that complexity may be an advantage — it may even be necessary.
The first time anyone who’d ever deployed a J2EE application saw the Ruby on Rails screencast, they likely thought “Wow, you can write a very basic single-table CRUD application faster than I can deploy my WAR files!” Not every problem is really, really big and not every problem is really really complex. Far fewer problems are as complex as we make them.
Given the complexity of ERP or CRM and every other interoperating TLA, I also understand the desire for a service registry and an efficient and decoupled enterprise bus. There’s complexity of administration and interoperability, and business analysts and software developers and software integration consultants. Modeling how you actually do your business and make your money and interact with customers and suppliers and employees means writing software more complex than a bare-bones weblog. It’ll take more than fifteen minutes, but that’s fine.
However.
If you have already installed and configured and customized this software, with services registered and running and discoverable behind appropriate access controls, you have an amazing opportunity that you can’t replicate with manual, paper-based practices. People can glue together services and components and queries to make their own applications and solve their own problems themselves.
That is what I appreciate about Composition on Grails. There’s still a learning curve to to know which services are available and to discover their properties before gluing them together. Building an application isn’t as easy as making a flow-chart and connecting each little box to another little box with an arrow and pressing Deploy. You must still write code.
However, writing a little Groovy that connects to the entire cloud gives you almost as much of the power as writing a full application against all of the official APIs with much of the ease as drawing pretty pictures. If I needed a small application to correlate book sales by language with regions of North America, I could write it in a couple of afternoons without begging our IT department to prioritize or schedule or spec it.
There are reasonable questions about who should be able to do this and service level agreements and resource intensive questions and access controls. Consider them. Still, I’m all for anything that moves power away from the high priests of computing to the rest of us, to improve everyone’s life and work.
I asked some probing questions between bites of lunch. They chose Groovy as it’s a decent language built on the JVM with some simplifications and better abstractions than Java, while following the Java language model. Strong Eclipse integration helps; it’s a foundational technology for SAP NetWeaver. JRuby and Jython are probably right out, for the near future. Due to the way SAP’s enterprise portal software works, they had to make some changes to the standard Groovy on Grails view system, at least for the current releases.
Basically, it’s early software still under development.
(During the demo, I asked a question about the separation of concerns in the view and controller classes. Will looked at me and said, “You must be chromatic. We should do lunch.”)
You likely won’t get official support from SAP for building applications with Composition on Grails any time soon. Don’t let that stop you. Their traditional model of building big, powerful, vertically-scaled application stacks communicating in a service cloud won’t go away, but there’s plenty of room for smaller, targeted applications written in agile languages such as Groovy, or Python, or Perl, or PHP, or Ruby to emerge and grow and prove their utility.
I feel a little silly for thinking that a large middleware company like SAP wouldn’t ever think about building applications in a more agile way, but I’m glad to admit that I was wrong. Here’s to finding new ways to simplify our software and to build useful things.
Update: Moya Watson and Will Gardella have just told me that the project has changed its name from “Composition on Rails” to “Composition on Grails”, so I’ve updated this entry accordingly.
Obviously this isn't your fault, but I find it mildly irritating that a Groovy/Grails-based technology uses "Rails" in its title.
@Reedo, that confused me for a bit too. I keep wanting to call it "Composition on Grails".
“If I needed a small application to correlate book sales by language with regions of North America, I could write it in a couple of afternoons without begging our IT department to prioritize or schedule or spec it.”
Well, if you could export the needed data into say CSV format, you could use statistical functions in your spreadsheet software to do the job. I find it shameful that programmers are still needed for such trivial computational tasks; were the users given tools powerful enough, they'd be able to do much more in much less time. As I really believe in "power to the end-users", currently I'm creating a graphical interface that enables them to tinker with the data in a relational database no harder than creating a pivot table.
You're right- the name is confusing. In any case, I just got a polite note from DHH asking us to change it, so look for a new project name in the next few days.