Category Archives: Enterprise application design

by

User experience in an enterprise system

I have a decided fixation on ‘user experience‘.  However, I couldn’t tell you what I am looking for exactly.  This is an attempt to remove the fuzziness.

It seems to me that there are two primary questions.

  • Who are the users anyway, of an enterprise system?
  • What should these users be able to expect from a system?

The users of an enterprise system

Anyone who interacts with the enterprise system in any way at all, I consider its users.

  • Employees who use the system to conduct the business of the enterprise.
  • Tech folks who create, maintain, enhance, and run the system.
    • Managers
    • Programmers
    • Testers
    • Dev Ops (Software configuration folks, System Admins)
    • Software Operators
  • Business partners who use the system
  • Customers who use the system

All of these folks, in their various capacities, must have good ‘user experience‘.   What does ‘user experience‘ mean to each of these folks?

Common to all users

In this post I will only list behavior that I believe applies across all classes of users.  In subsequent posts, I’ll go more into what might make sense for various individual classes of users.

Business functions must exhibit the following characteristics.

  • They must be performant – must execute just as fast as necessary, regardless of the load on the system.
  • Failure of a function must not leave the system in an incorrect state, which might require invasive, and manual cleanup.  Rollback as necessary.
I've been involved in exercises where dealing with the errors that 
production code left in its wake, became a full time job.  There are 
many reasons why a development task ends up here, including holes in 
business analysis, code construction, and testing.  None of this is 
rocket science.  The relevant skills can be acquired, and these potholes
can, and must be avoided.
  • Every business command must be available through three avenues – a GUI, a DSL that you use at the command line, and as pluggable units in external systems like schedulers, ESBs, and workflow management systems.
A single API must support all these various methods of invoking business
functionality.

You are taught to create interfaces that are appropriate to all levels 
of expertise.  Stepping through 8 web pages in order to make one edit 
on the 9th page might be acceptable for non-tech savvy customer service 
rep.  However, a developer, who is dealing with a customer support issue, 
does not have to deal with the overhead of all that UI.  Two lines of 
script ought to do the same job just nicely.  You could use SQL and change 
data directly in the system's database.  But wouldn't you rather go 
through the application's infrastructure, which presumably has essential 
checks and balances in place. That is where the domain specific language 
(DSL) comes in.

A DSL would also enable functional testing, while avoiding the drudgery of 
dealing with the UI.
  • You must be able to access the business function from the device of your choice – desktops, laptops, tablets, phones.
This is where the world seems to be heading.  Either get on the bandwagon, 
or be left behind.
  • Command line access must be in the form of a domain specific language (DSL) with which you can write scripts to tie together various functions in a workflow.
  • Long lived commands must have these behavior.
    • Run them in the background, and bring them into the foreground as necessary.
    • Expose current status, and progress.
    • Allow you to abort in the middle of execution, and return the system safely to the previous state.
    • Allow you to stop and resume where you left off.

Required skills 

Not every project, at every client, will ask for all the features described above.  However, I believe it represents a set of skills that an engineering outfit can reasonably be expected to have.  I want to be able to deliver this functionality.

There is little here that is exotic.   I only see three or four main streams of skills, all of which are well understood, and well supported.

  • Learn to measure, manage, and deliver performance.
  • Learn to architect business functions such that they lend themselves to manipulation from the command line, and GUI.  This mostly consists of creating well-designed APIs.
  • Learn to create GUI in a browser neutral fashion, and for various mobile devices.
  • Learn to create well-engineered and expressive DSLs.

Is it practical for a small and competent team to be able to develop these competencies, and employ them  successfully?   I would have to think so.

 

by

I want to create software that is like Tom Binh bags

or  I want to create software like Tom Binh makes bags.

I am impressed by Tom Binh bags.

It makes me happy to carry around a Tom Binh bag.

I am so glad that it has been possible for someone to make a success out of working in just that manner.

Craftsman

Is Tom Binh a craftsman?  Is that what it is?   Do I want to be a software craftsman?  That is possible, isn’t it?  There are people out there that see value in that, don’t they?

I have been doing computer programming of some sort or the other for almost 17 years.   I don’t feel very accomplished.  I feel a distinct lack of skill.  There are so many questions, which I don’t know the answer to.  I am not sure I am an expert at anything.  I know a little bit of a lot of things.  I can be relied on to ask good questions, I think.  I have been known to work hard.  I play well with other people.

At best, I think I have the aptitude to be a craftsman.  I keep thinking that you are a craftsman when the skill that you ply is fairly complete, and second nature.  I am not that, yet.  I have promise.  That is the most I can say for myself.

How can I work at something for 17 years, and still not be very good at it?  Are you ready for this?   It turns out that I don’t have to be.  In software engineering, this strange slice of the working world, I can provide a lot of value, without being very skilled at software engineering.  Despite my shortcomings, if software engineering skills were graded on a curve, I am sure I would fall at a decent spot.  I am good enough for a lot of environments.

Quality

When I see a Tom Binh bag, I think, “That is quality“.

A Tom Binh bag is an inspiration.   No, it is more.  A Tom Binh bag is an aspiration – for me, carrying one is an act of prayer.

But what am I aspiring to?  What does “quality” mean to me?

I am not sure I can explain it.   I could resort to that old saw about pornography – we can’t define it, but we sure know it when we see it.

Tom Binh’s bags show attention to detail.  “God is in the details“; sign me up for that church.

Every little part of the bag has a well thought-out purpose.  Every little part of the bag fits, as intended, into its surroundings, and all the little parts work together, as intended, to serve a larger, well-defined, goal.  Unmistakably, the bags are a rigorous architecture, and design, made flesh.

I want to create software that exhibits the same characteristics.  Is that too much to ask?  The answer of course, is yes.

Why don’t more people carry Tom Binh bags?

Good, but not worth the money

The bags cost more money than some folks want to, or can spend, on luggage.  Regardless of the value the bags provide, the finances just don’t make sense to these folks.

Software engineering shares this issue.   Higher skilled engineers are expensive.   Business, often does not want to spend that money.  The work produced by inexpensive, but low skilled engineers, is deemed good enough.

There is a school of thought that holds that a higher skilled software engineer is worth several low-skilled engineers.  Alas, I don’t know how to make this case, even though I have seen anecdotal evidence to support this idea.

This is not an entirely lost cause, but close.

I am looking, and I am not liking

Some people simply are never going to like Tom Binh bags.   Even when money is no object, they see nothing there to their liking.

Have you ever had to deal with a business stakeholder who wants a completely inexplicable UI?   The customer is always right.  You can only walk away from this.

Craftsmanship dictates low volumes?

I might be wrong about this.  Very little of Tom Binh’s production process seems to be mechanized.  Tom Binh is not in the mass manufacturing business, I think.  He creates quality with meticulous, manual, effort, by a small number of highly skilled folks.   Naturally, this means they can produce only so many bags.

Software does not have this limitation.  Mass manufacturing is trivial.   It is the master copy, however, which is the challenge.  Craftsmanship can indeed be brought to bear in creating and maintaining that one master.  However, we all know that is easier said than done.  Some days I understand why.  Some days I do not.

Colors

Oh man, do I love those colors!

tombinh-colors

I wonder, what color is the code I write?

What color is your code?

by

How to avoid sending null/empty fields between a RESTful service, and a client?

By it strictest definition, a RESTful service sends and receives ‘resources‘, which when seen from an object-oriented perspective, are largely the objects of your domain model.  An insurance policy, a bill, a payment, a car, a truck, a driver, a patient, a nurse, a clinic, etc.

Often, an instance of the object that you are putting on the wire has null fields.   Here is a patient at a clinic, whose middle name and date of birth, we don’t have.

{
       "patientId": "THX1138",
       "firstName": "John",
       "middleName": null,
       "lastName": Patient,
       "dateOfBirth": null,
       "address": "1,  Illness From,  Bankruptcy, HA-00000, USA"
}

In the mobile world, where we now pay for data usage, and where connections can be slow, it might be useful to minimize the amount of data we throw on the wire.   When the mobile app retrieves the above person, John Patient, I want to drop the fields (middle name, and date of birth) that are null, and send just this.

{
       "patientId": "THX113",
       "firstName": "John",
       "lastName": Patient,
       "address": "1,  Way Ticket To,  Bankruptcy, HA-00000, USA"
}

Further, I want the mobile app to be similarly discriminating when it sends data back to the RESTful service at the server.

In effect, the marshalling mechanism at both ends should be able to create the patient object with just the data that is available, and leave the rest of the fields null.

Javascript works that way natively.   If I was running Javascript at both endpoints, the core language itself would pretty much give us this behavior (Ah, node.js!).

I expect this is possible in other environments too.   In particular, I will need to look into this for the following.

  • RESTful service in Java, talking to 
    • Android App in Java
    • iOS App in Objective-C
    • Javascript MVC

68 dollar question

Is this really worth the trouble?   Will this really produce a lot of efficiency?

Is it even worth pursuing this question?

When data usage costs money, and connections can be slow, and intermittent, why would you want to carry unnecessary baggage?  Even in the best of circumstances, why would you want to?  This sounds like it ought to be a first principle for any mobile app.

But, we do want to watch out for ‘premature optimization’ – getting clever too soon, or even unnecessarily.

Hence, we will need to know how to test for this?  How do you simulate, and test spotty mobile connections?

Related questions

  • What other techniques exist for dealing minimizing the data usage of your mobile app?
  • What other techniques exist for dealing with intermittent, or slow connections?

These just seem a more severe variation of a problem that has been around for longer than the mobile world – how to build a UI around large-grained, stateless APIs.   So there are answers out there …..