While collecting some views of Application Architectures, I came across yet another way of defining an application. I liked it, as it aligns with my reasoning that an application is simply the automation of a business function using technology.
An analyst named Tom Richards wrote the following in an Enterprise Application Integration paper:
“A business process is not just a systems topic; it is also a business management
and human performance topic. It is a series of activities,
grouped into three areas, that convert business inputs into outputs:
• Inputs – data, outputs from another linked process, and/or an event
(sometimes referred to as a stimulus) that initiates the process and/
or provides the information needed to perform a task;
• Work – rules and workflow that process the inputs, including skill
sets, knowledge, motivation, feedback, performance standards and
• Outputs – the result of the process, which may include data or a
response or a link to another dependent process.
Automation performs a vital supporting role in assuring the desired outcomes
of these activities. Automating a business process allows the consistent
execution of the process; consistent application of business logic,
policy and rules; and increased, scalable capacity.”
In my organisation a short document exists for each major business application. This is called the Application Architecture Document and it follows a consistent framework to address specific topics for each application: Business objectives, users that use it, business functions performed, information stores maintained, platform and tools used for development and testing, integration with other applications and the infrastructure (hardware) that it runs on. This is an adequate view for business, solution designers and architects who require an overview of an application.
So what artefacts make up an Application Architecture? It can be a huge variety of things, depending on the views that are required. A business view might for example be required that shows what major business applications exist in the organisation. A Solution Designer view might be required for an application that shows how the application works. An Enterprise Architect view might be required that shows how well an application conforms to the architecture standards adopted. A view might also be required that shows the business objectives, data (information) elements and the infrastructure that the application is deployed on – all within the same view.
The next few blogs will look at what is contained within an Application Architecture. The Applications layer features somewhere between the Business and the Infrastructure layers (refer frameworks previously discussed). An application typically includes the data it uses or maintains, and this data is usually within the application’s control. An application is really an IT Solution, so it can be an off-the-shelf package that is implemented or it can be an in-house developed system.
KM is another topic in the Information Architecture. Knowledge is Information – albeit a special category of information. As with Content Management, an organisation should include in its Enterprise Architecture a strategy regarding what tools will be used for KM. Such tool(s) should meet the requirements of the business in terms of ease of use and ease of information retrieval. It must also take into account special user requirements such as after-hour availability of information and availability off-site, e.g. in work-from-home situations. Due to the nature of Knowledge it is especially important to govern the implementation of the EA strategy around this, as Knowledge should not be duplicated or maintained in seperate, disparate toolsets.
ECM is one of a number of topics that feature in an Information Architecture. Content makes up Information. For the purposes of Enterprise Architecture an organisation should have a strategy for how it wants to store Content and what tools it wants to use to manage the Content and apply it to deliver the Information required to run the business. Content can consist of various categories such as Business (e.g. business process rules), Parties (e.g. Customer and Intermediary information), Product, etc. Information about IT applications and Solutions can make up another category, so can Information about programmes and projects (of a less permanent nature). For each of these categories the EA might propose different tools to store information to make it available to the Enterprise.
The accompanying diagram is one of hundreds of views that can add value as part of an Information Architecture. This diagram shows the current landscape of enablers that support Business Intelligence (BI) in an organisation. It shows the various enablers used for BI, according to the layers of a framework similar to one that I introduced in previous blogs. The top layer is about presentation of BI to the users and the bottom layer is about infrastructure, i.e. the hardware on which the reporting is run. This view illustrates the variety of enablers used in this organisation – a picture that is obviously not ideal as it clearly shows the competing BI tools, e.g. Oracle, SAS, MSRS. However, this view allows the organisation to focus on simplifying its BI landscape if it wishes to reduce its IT costs in this area.
I mentioned that various methods and tools are available to support a BI programme. One such a tool (perhaps rather a method or discipline), has the objective of making data centrally availabe for extraction and analyses. This is referred to as Data Warehousing. DWH as part of an Information Architecture requires its own principles and standards in order to succeed and ensure that the potentially huge sums of money are well invested. This is easier for smaller organisations where coordination and governance can be applied with less effort than in larger organisations. DWH can be skills intensive, for example if SAS or SAP Bi tools are used, it will require skills specific to these platforms to develop and maintain the DWH and processes to update, extract and analyse information.
Another workstream that could make up an Enterprise Information Architecture might be Business Intelligence. This workstream will have its hands full with unravelling the plethora of theory and practices around BI. However, it is again firstly important for the buiness to be clear about its expectations of BI and, accordingly, what it wants to invest in it. BI really ends up being a discipline that gets adopted by the business and IT in partnership for it to be successful and to add value. Various tools and technologies are available to support BI, and these should be decided in principle to avoid different business units acquiring their own. I have seen the mess that an organisation can find itself in if this is allowed to happen – disparate sources of data, disparate tools to mine it and huge effort to co-ordinate the results.
Today we return to Information Architecture and have a closer look at what this might contain. Many topics could fit into the IA domain. It can be a challenge to put into context terms such as Data Models, Business Intelligence, Knowledge Management, Content Management, Data Warehousing, Master Data Management and many others that relate to Information. Some organisations might bundle all of these together as “Enterprise Information Management”, but even then it will make sense to define and scope them into seperate workstreams that become part of the Enterprise Architecture programme. One workstream might define the highest level models of the data that the organisation uses – e.g. product data models, customer data models, commission data models. In my organisation actuaries play an important role in shaping the product models. In fact, I see these actuaries playing the roles of business architects to a large extent.