Erg. So, for years I've been involved in deployments of business process software and enterprise software on customer sites. Architecture, design, coding, requirements gathering, project planning, all sorts of tasks you couldn't possibly take seriously unless you were in the biz, I've done.
And here's a little system architecture conceptual framework: there are three stakeholders for a system, the specifiers, the customers and the users.
- It's important to please the specifiers. The customers listen to them, and they pull your offering out of the vague phase cloud called the marketplace. Without connecting through the specifier that customers in your target market trust, you're not going to move a lot of CDs, much less professional services hours.
- It's important to please the customers. They pay for stuff, and their complaints and needs matter. Customers have particular drivers that you want to identify and satisfy. They're more important than the specifiers, and your relationship with them is typically deeper and lasts longer. Even if you lock a customer into a contract, you want to avoid angering that customer, as your only backup is your personal relationship with that customer's boss, which has its own pitfalls.
- It's important to depress and degrade the user to the point where they don't feel worthy enough to make a stink. OK, I didn't learn that at MIT. But, it seems to be implicit in many requirements gathering processes and project plans. When it comes down to brass tacks, users don't do a heck of a lot for you, and don't make decisions that impact you. And they get in the way of providing value to customers and specifiers. Would you add 100 hours to the project plan to keep 1000 users each from spending an hour hunting for the any key? Do you really want to pay native American English speakers to write your documentation?
So, in typically self-defeating fashion, I keep an eye out for the user, and provide advocacy where I can. Mostly I try to shame people into treating them less shabbily, or pull all nighters trying to improve usability, or trying to improve the flow and reduce the user's interaction with the system.
But, mostly I try to avoid
using enterprise software. I'm like an aeronautical engineer who refuses to fly. And, I'm generally successful.
But,
Oracle's Siebel caught me tonight in the full force of its glory. The human pain was all ours on the
DiRT tonight, as we were in training for the new software
Acquis apparently talked the American Red Cross -- and
ARCGNY is the first chapter to use it -- into 'configuring'. The toughbooks and little portable printers were cool, but remember the internet bubble? Remember how introducing a browser based thin client could make you look like you 'got it' and pump up your stock valuation? Software architecture never recovered.
The first sign you're
USTWaP is the two splash screens. One splash screen for a while, and then nothing. That's right. There was a visual artifact to let us know a background service was loading. Thanks.
Then the browser launches, and
the browser app has its own splash screen. Shouldn't 'browser app' and 'splash screen' be exclusive concepts? It's not thin in the sense that its fast and has a small memory imprint, it's thin in the sense that it's browser based. And this is not just any browser, this is Microsoft Internet Explorer. Are you looking for speed, stability and isolation from the operating system? That's why the good Lord gave us
Opera.
So, you see where this is going. Why would you need a server application on a thin client? Well, it detaches. Something's got to host the thousands of enterprise java beans that are undoubtedly in there.
It might help you if you knew what this was for. At disasters, we register people, we evaluate their living spaces for damage, we arrange housing, and we cut them debit cards. Generally those four things, although we can arrange on-site counseling, medical attention and a bunch of other useful stuff. The software centralizes the processes and standardizes the data. It increases reliability, reduces rekeying, and should improve the quality of the data and the services the client gets -- it also enables us to provide a little more of those services up front, and maybe remove the requirement for a follow-up trip to the chapter altogether.
Further, it reduces the back end processing cost to the Red Cross, which is a big deal. I'm not complaining about the software because it's a bad idea.
I'm complaining about the software because its architecture is crazy! We have trained staff doing four things to a small group of people. Using ERP software. Why do we need a database management server, and application server and a web server on our very cool Toughbooks? Because we're in the field and aren't continuously connected. Does it sound like someone's solving problems backwards? To add insult to injury, we have to connect and synchronize manually and separately.
Of course, in order to connect our thin light clients to our beefy local server applications, we need hyperactive scripting and local objects to capture and report everything that goes on in the browser. This makes Internet Explorer chill out and reflect for minutes at a time. Our teacher encouraged us to use back buttons when possible -- not to gratuitously show off the session management, but because he'd been using the things in the field for weeks and couldn't work out how else to navigate. We got lost a lot, and nothing could save us.
The good news is, we're all certified. We had set aside two hours to walk through a case study, do some abstract trainings, do another case study (a third if we had time) then take a certification test, starting at 6:00. At 8:30, we just decided we'd finish that first case, break for dinner and take the test -- I only got dinner because the store failed to lock its doors and I slipped in at 9:03. We finally struggled out of there at 11:00, after having trimmed the certification portion pretty savagely.
The teacher is an actual responder (he was the staff guy in
my last DiRT posting) and insists they work great in the field, so I'll withhold judgment. But, I did feel like I was being punished for every time I let expedience or thrift be my guide. Or, more likely, politics -- it certainly didn't look like it had been made easily or cheaply. So, sorry. And I'll continue to do what I can. But, you users. You've got to stand up for yourselves.
