Information technology is neither a goal in itself nor an abstract set of applications and relationships. Behind any useful IT implementation is a worker, and the way IT relates to that worker is paramount in achieving objectives.
Whether the work is done by an enterprise architect or an application architect, a top-down, user-centric design of the places and mechanisms for interacting with IT is critical in ensuring that business targets are met. Outputs to workers, interfaces to other application components, and job scheduling all have to meet business benchmarks first and IT schedules second.
A clear process is essential to prevent tying up critical IT resources.
An important component to an architecture plan and design is structuring outputs to match business process requirements. The best practice is to separate output generation from application processes where possible. That means reports should be generated from databases using generic report-generation procedures rather than built through specific application development. Most report generators provide a quick and easy way of formatting output, to the point where many can be used by line personnel directly. This reduces the cost and delay in making changes to reflect modifications in business practices or workflow.
Where it's not possible to generate an output from an external generator, the best approach is to separate the graphical user interface functions from the application, passing a transaction payload between the actual update logic and the GUI. Most architects will specify an XML-based exchange because the format is easily translated into something that can be viewed in a browser. A generalized Web presentation module may be the best way to create worker screens.
Don't fall into the trap of specificity! Except where data volumes would create prohibitive traffic, it's best to pass the entire transaction context (input, changes, results) in the transaction payload rather than pass the fields currently required for output. This will accommodate changes in information needs without going back to change the application components.
Application components should create a data map containing all relevant and available data and present that map to an internal module that creates the application program interface needed, with the specific data formats and content the other process requires. The same thing should be considered on the other side of the interface -- the receiving process should accommodate the full range of available and relevant information and populate the fields with the presented data.
In this process, it's important not to simply pump the full data repertoire through the interface to prepare for future requirement changes. Even where traffic implications of this decision would be limited, there is a compliance risk. The actual interface should present only mandated fields. This interface handler can be changed to accommodate different workflow needs.
Both output creation and interface creation under this Agile model requires special governance practices because of the ease with which additional information can be exposed. There is always a risk that presentation agility at the output or interface level might violate information security practices. Each agile output/interface process should be reviewed to ensure that this risk is managed.
In an architecture plan, job scheduling is an often-overlooked part of the worker support process because architects tend to focus on application logic and workflow and not timing. The challenge is exacerbated by the fact that most attention is focused on core business applications that are transactional in nature, and thus not formally scheduled. Significant problems can arise if job schedules aren't considered, because information is often not timeless in the literal sense; it has a schedule that analytical/reporting jobs need to accommodate.
More on architecture plan and design
Using EA principles to facilitate governance
Designing architecture for cloud services
Creating an SOA center of excellence
The largest issue with analytical/reporting accuracy is a failure to align job cycles with the natural information cycles. The problem period most often reported by businesses is when analytical/reporting jobs focus on a period from the present to the end of the prior quarter. Most companies create derivations or aggregations of production data to facilitate analytics and reporting, which are scheduled to run at longer intervals.
It's not uncommon for queries to run requesting data not included or complete. This can generate inaccuracies that can contaminate business decisions. It's smart to have any analytical/reporting jobs check date ranges being processed to ensure they don't fall outside the represented range.
A second issue with job scheduling is the timing of batch or aggregation functions relative to production activities. These background jobs should not be run during prime production periods because of the risk of interfering with the real-time transactional applications. They also can't be scheduled where summarization tasks compete with reporting functions that rely on the summaries.
Architecture planning and designing best practices include the following:
- Start with a schedule of low-production periods
- Slot regular aggregation/summarization jobs into fixed and dependable slots daily, weekly, etc.
- Identify remaining low-utilization periods for analytical/reporting jobs
Some ad hoc reports are always necessary. To accommodate these, it's best to limit the number of people who can request them without approval and to review the impact of the request in terms of timing and the type of information. A clear process is essential to prevent tying up critical IT resources in assessing the risks and benefits of every extemporaneous job. A little planning will save a lot of time and headaches later.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.