- Make sure the first applications which introduce information integrity are the best in market (change the budget if needed to achieve this!).
- Create a system of living documentation for application requirements for all to see, understand, and modify.
- Encourage sharing of ideas on how to reduce the amount of interface custom rules, pushing the business rules back closer to Users and front ends.
- Reorganize through a program/project management office the influence that business analysts have on change management and how they can get results quicker from infrastructure and application engineers.
Monday, June 23, 2014
You don't see anyone commuting with a muscle car from the 60's on the highway, so why do we tolerate old, upstream applications like patient registration, accounting, and interface hubs which introduce major data quality issues that cascade downstream to other dependent applications. Let’s try to frame these issues in the following ways:
1. Historic Applications
a. A patient registration system can be the oldest system in a healthcare setting, along with billing and accounting. This is the frontend system which feeds most other systems, why is it neglected?
b. Any tier 1 applications which were deployed at a company were designed with requirements that lack the proper enterprise expanding capability. This is just inherent in any pipeline application.
c. These apps are the most expensive and are most difficult to change. They have the oldest looking UIs.
2. Over the wall responsibility
a. The application administrators work in their own silos. Take for example the typical groupings of IT: Financial/HR, Clinical, Imaging, Administrative, LIS, ECM, etc.
b. Each of these has its own management hierarchy, therefore each has its own agendas and objectives.
c. Differing departmental goal priorities often clash between these application groups. One Director has a goal which is aligned while another does not.
3. The interface cannot hold everything together
a. To accommodate the “historic” application’s lack of flexibility or expense to customize, the interface takes on the role of tracking and rules for filtering and routing data.
b. In addition, to fill in the gaps that the “over the wall” mentality introduce between applications, interfaces help, however, on the flip side they create problems as requirements and applications change.
4. Infrastructure Attitudes
a. Systems admins don’t have the time to review new requirements, they are busy with storage and performance issues.
b. DBAs can’t be bothered by development questions
c. Storage and asset management manager only care about keeping the lights on.
It’s no wonder data quality suffers as historic applications become more rigid, departmental priorities clash, interfaces act as super glue, and infrastructure have their heads in the sand. There is not enough transparency and cooperation between the application “owners” to work as a true enterprise system. Of course, some companies are better at managing quality of information and have more resources to do so. However, a few foundation changes could make a difference: