Posts Tagged ‘Language’
*ilities that get lost in translation
A lot of words that get thrown around during discussions between business and technology folks are “overloaded” – used to mean different things for different parties. Often parties involved do not recognize this and think that every one is on the same page until the outcome proves otherwise.
Every Technical architect knows the importance of stuff like – availability, reliability, scalability, flexibility and performance. Together these are often called – *ilities and mastery of these is a sign of a good architect. Now, as you move up from the role of a pure Technical Architect to an Enterprise Architect and beyond you have to take an organizational view rather than a systems centric view. Often these require conversations with business heads on their business processes and pains. Sometimes these conversations will include some or all of the *ilities but they mean different things to the business.
Let us take a look at what they mean to both parties
Availability (Technologist) – System uptime.
Availability (Business) – It includes system uptime. It also includes “accessibility”. Is the system available when I am on the road? Is the data available on my phone?
Reliability (Technologist) – What is the accepted “Mean Time Between Failures” (MTBF)? Reliability combined with Availability gives you the acceptable downtime per day/week/year. To a lesser extent this also answers the question – Is there enough system safeguards to maintain data integrity?
Reliability (Business) – Rarely do the business users link “reliability” with “availability” the way the technologists do. For them reliability is all about data reliability and data freshness. Can I rely on this data? When was this data last updated?
Scalability (Technologist) – Can the system architecture handle the growth in data/ transactions. What is the scale out strategy – vertical or horizontal?
Scalability (Business) – Can the system handle growth in business locations (new offices, new markets, new countries etc…)? When do I need to add people to handle transactions in the system?
Flexibility (Technologist) – Are parts of the system behavior configurable? Can changes be implemented easily without having to rewrite/ recompile large parts of the system?
Flexibility (Business) – Can the system handle changes to “business processes” on the fly?
Performance (Technologist) – What is expected and acceptable response time for the system for a specific action under a specific load condition?
Performance (Business) – I need the system to respond immediately to my action.
Most of the challenges I have encountered with business users is around – scalability, flexibility and performance. I think the “scalability challenge” can be easily overcome if we understand what the business user is asking and we drop the system centric view to take an organizational view. The “performance challenge” is also relatively easy – it is about getting the users to qualify the actions and quantify the acceptable time to complete the action.
I think the greatest challenge is around “flexibility” - often (not always) what business wants is a system with rules where rules can be changed on the fly. This would break even a system that has a user-friendly rules engine. And, just because they ask for it does not make it right. It is important that the business understand the concept of standard process, alternates and exceptions. It is also important for the business to have release cycles around business processes just like IT has release cycles for systems. Changes to business processes involves communication, collaboration and confirmation.
