computers should be less friendly

SAP is really starting to push the Composition Environment at this TechEd.  Recently I’ve started to think a lot about this topic given that it could radically change the way enterprise developers do their jobs.  This environment must also come with a new and necessary workflow akin to the Design – Developer workflow that MS and Adobe are both talking about.  Adobe has recently released Thermo which tries to address this gap with software.  Ryan Stewart gives a great rundown of the Thermo and the importance of this interaction:

It’s all possible because Thermo is a jewel of the designer-developer workflow. We can rely on Adobe’s incredible experience in creating design tools with our growing and powerful development framework, Flex. A good designer-developer workflow is so important to creating great RIAs. You only get great experiences when you combine the right brain of a designer with the left brain of the developer and let them collaborate.

Although, the design-developer paradigm is a good starting point it isn’t nearly complex enough ( not to say this interplay isn’t complicated but, come on if you put the wrong color somewhere your enterprise doesn’t stop running ).  The design-developer workflow relies on something else too — that both parties have at least a tacit understanding of what the other does.  There has been a lot of talk on SDN/BPX about this but, I am unconvinced that a common “language” is all we need. 

Life Guards

Development-QA-Production, the 3 tiered architecture that helps stabilize SAP development.  How will this be implemented in this workflow?  Where do the we do business process re-engineering?  Who tests these changes?  How can we communicate the shared responsibility?

A common language doesn’t solve this problem — it would seem more like IT would have to transition resources to be the life guards at the pool.  Changing workflows and/or “document flows” can radically affect  the running or compliance of the enterprise.  Who serves as the gate keeper for these things?

Treading Water

Right now the average IT department is trying to do more with much less.  They are trying hard to build new functionality for their businesses in a choreographed manner, using all manner of controls from code reviews to OO design patterns.  One big question is how does the business person even ask for this new functionality?  What if there isn’t something in their enterprise service repository or what if a field they want isn’t there?  Do they create some vast wiki system?  Do they open an OSS message ( although we would have to make the GUI a bit easier to deal with! )?  Ah, I know Solution Manager — open a message there.  Great. 

We use certain programming techniques to do more with less, “Why not write this section of the project as a set of subsystems and a facade so we can use it again if we want.”  How can we see these interconnections if IT is just trying to tread water supporting these new “business process reengineering” tasks.

Leaky

I guess my main problem is that I know enough about programming to know that even when we have nice abstractions they never work exactly as planned.  “All non-trivial abstractions, to some degree, are leaky.”

…you can’t drive as fast when it’s raining, even though your car has windshield wipers and headlights and a roof and a heater, all of which protect you from caring about the fact that it’s raining (they abstract away the weather), but lo, you have to worry about hydroplaning (or aquaplaning in England) and sometimes the rain is so strong you can’t see very far ahead so you go slower in the rain, because the weather can never be completely abstracted away, because of the law of leaky abstractions.

When someone goes to change a business process they are using abstractions to deal with the complexity of business.  They are using objects created by programmers to represent the world and when we try and put them together there will be instances where they leak.  The biggest problem with this is that the person doing the re-engineering isn’t going to know.  They are just going to try and move blocks around till it works right and this is dangerous.  Adding more steps or trying to circumvent the abstractions inherent leakiness is bad and will just produce poorly designed processes. 

Mark Spitz

Success in this is possible — we just have to realize that the only way to do this is get people on both sides who have a shred of understanding about what the other half does.  The optimum process has to have a collaborative model at it’s core where the person doing the re-engineering is leading the way.  IT would continue to support this function with technical knowledge and broad enterprise experience.  Here is an over simplified version:

See even I can do swim lanes!

This entry was posted on Monday, October 8th, 2007 at 9:55 am and is filed under SAP, SDN blogger. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.