Trying to Hit the Nail on the Head

Because of “new” ideas such as workflow and BPEL our ways of identifying and analyzing automation needs have changed. More and more, we do no longer start at what a user needs, but at what needs to be done; we start analyzing the business processes first. And that’s a really good thing.

Now, when we have our business processes, brave people dare to say that the y are in fact the requirements for the software that needs to be created. Very courageous even say, that they define – or at least inspire the design of – the (software) services that will combine into the software. (The reason for this is, that it’ll make your life as a software designer a lot easier to keep in pace whenever the business processes change.)

But when we “really” start designing/analyzing that part of the business process that needs to be automated (or supported by software), it’s asif we take a step back and start thinking: now, how would a user want to do this… and we recombine everything again, even if this means that means making the underlaying services less functionally coherent.

Now, let’s think of humans as just a “biological” software component implementation.
Humans interact with software using a very specific protocol, which translates incoming data to visual stimuli (the GUI) and keyboard and mouse actions to outgoing data.

The model that mostely is used (not the model I present here), has too many limitations. The entire webbased/thin clients wave for example, uses a pull model, where data is only shown to the user if the data is pulled from the backend; in most applications, there is no push. However, in real live applications, there often is a need for it… and it’s better supported by a mental model that looks at humans as components as components do not only have required interfaces (with operations that must be provided by another part of the system), they also have provided interfaces (that can be called by other parts of the system).

More and more human interventions will get automated. It might not look as a happy future, but rule engines could replace some if not a lot of the “manual” human jobs done today. Replacing these tasks with a piece of software will be a lot easier, if the interaction was embedded in component.

…

I’m sure that some people might be offended by the ideas in this post (especially the part about replacing a person with a rule engine), but I’m going to give it some more thought to see where I could end up with this train of thought. And I’m also going to investigate on how other protocols are formally specified. Perhaps that might give me some idea on how to specify the computer-human interaction more precisely.

“I have always been a huge proponent of candor. In fact, I talked it up to GE audiences for more than twenty years. But since retiring from GE, I have come to realize that I un­derestimated its rarity. In fact, I would call lack of candor the biggest dirty little secret in business.

What a huge problem it is. Lack of candor basically blocks smart ideas, fast action, and good people contributing all the stuff they’ve got. It’s a killer.

When you’ve got candor-and you’ll never completely get it, mind you-everything just operates faster and better.

Now, when I say “lack of candor” here, I’m not talking about malevolent dishonesty. I am talking about how too many people-too often-instinctively don’t express themselves with frankness. They don’t communicate straightforwardly or put forth ideas looking to stimulate real debate. They just don’t open up. In­stead they withhold comments or criticism. They keep their mouths shut in order to make peo­ple feel better or to avoid conflict, and they sugarcoat bad news in order to maintain appearances. They keep things to themselves, hoarding information.

That’s all lack of candor, and it’s absolutely damaging.”

Mind you, this is not my writing: I copied from the great book “Winning” by Jack Welsch, former CEO of GE.
But I’couldn’t agree more and I advise you all to read the entire book, even if you’re usually not “into” those management books!

All too often analyst, designers and alike create models, forgetting the essence of models: they are communication tools!

If you keep this in mind, you’ll avoid to make two common mistakes in modelling:

• Do not create a model simply because you can. Only create the model, if it is needed to facilitate some communication. Now, keep in mind that the communication I’m talking about does not necessarily have to take place in right now, or even in the near future. Weeks, month or even years can pass between the end of a project and a change request. A model of the overal application architecture might come in handy to communicate the overall structure of the application to the people who will implement future change requests.
• Do not use a model  in your communication, that is not understood by the people you’re communicating with. A good example of this are data models: use a logical data model to communicate with business stakeholders.  Use a physical data model to communicate with your programmers and dba’s. Do not use the physical data model to communicate with your business stakeholders, as they will probably find it too complex.

Ok, I admit, it was a bit rude not to introduce myself. So here goes.

My name: Johan Nagels
My diploma: Masters Degree in Computer Sciences
My job: Senior Consultant, Technical Architect (Java) – although I prefer the title Software Architect – at AE, a Belgian consulting company (about 100 consultants), specialising in (software) architecture.
Other qualifications:

• One of 7 Knowledge & Competence Coordinators within our company (AE): I’m the one responsible for Java (and SOA);
• Sun Certified Programmer for Java and Sun Certified Enterprise Architect;
• IBM Certified SOA Solution Designer.

My whereabouts: I live, work, … in Belgium.

Want to know more? Feel free to leave a comment and/or send me an email to [my firstname]@[my lastname].be and I also have a profile on LinkedIn.

In my previous post, I mentioned that I’ve already tried to write some articles. Here are the two most recent ones. They both appeared in IT Professional, a relatively new bi weekly managzine on IT. Unfortunately, the articles are only available in Dutch and French.

• Service Component Architecture (SCA): Dutch and French page 24 and 25.
• Characteristics of Software Services: Dutch and French page 8 and 9.