Information system architecture, from methodology to implementation tools

With their increasingly critical role in businesses, information systems have become significantly more complex in recent years, with the successive additions of yet more applications, widespread use of SaaS, point-to-point interfaces, etc.

It can as a result be difficult for a business to gain a full overview of its information system and to ensure consistency in its structure and development. Behind the tangle of data streams running between applications, the disparities in data dictionaries and different infrastructure choices, the risk is that the whole edifice becomes impenetrable, resulting in massive inertia when it comes to making changes.

However, the demands of transformation (affecting business functions, the business plan, technology, the relationship with the wider ecosystem, etc.) make agility a crucial factor. This agility takes the tangible form of the practical demands an information system must meet. An IS designed for a particular point in time is no longer adequate; it needs future-proofing against the emergence of new requirements, constraints, innovations, and so on.The challenge of effective information systems architecture forms part of this context and strategic objective. Before embarking on any project, a distinction must be made between an information system and information technology.  The information system is part of the functional picture. It will therefore last much longer than any particular information technology architecture.

Review of the key points of information system architecture

The objectives of IS architecture

The objective of the IS architecture is to analyse, define and align the development of information systems on the basis of business strategy and processes, and depending on technological innovations.

Information systems’ architecture can be divided into 4 layers:

The architecture is intended to provide a consolidated view of the IS and offer a coherent plan to align infrastructure, applications, functional modelling, business requirements and business strategy, while taking the existing system into account.

The process is consistent with a point of view we have always firmly held at Blueway: architecture must be examined in a top-down way, i.e. the business strategy has to guide the direction the IS takes. Business decisions cannot therefore be influenced by technical constraints. 

How is the idea of information system architecture applied in practice ?

Avoiding the intricacies of expert debate, put simply an IS architect examines the four layers, the links between them and maps the existing structure following each layer (architecture diagrams). It is an opportunity to pinpoint any shortcomings and areas for improvement.

Taking strategy directions into account, the next step is to draw up the road map accordingly, and the various stages involved in switching from the current to the target information system in each of those areas. The approach is mainly top-down, meaning it is strategy objectives and business issues that direct what happens in the other layers. A number of information system design methods exist, such as Merise, SSADM, IDEF, UML, SAD, etc. which can be used to gain some perspective on IS architecture.

Interchanges, both between internal applications and with the broader ecosystem, naturally play a vital role in this mapping. The re-engineering exercise also aims to optimise processes and data flows within the business, and to guarantee a single version of trustworthy data throughout its lifecycle.

Consequently, taking a handful of practical example, an IS architecture exercise will provide answers to the questions: How is my data modelled ? How is data conveyed around the company? How is this data processed ? Are there any shortcomings and areas to be optimised ? How can business processes and dealings with the outside world be improved ?

Tools and software to assist in building IS architecture

There are two main categories of tools that can assist with an IS architecture project.

The first group is mapping software for each layer:

• Process mapping for the business process architecture
• Functional mapping for the functional (product delivery) architecture
• Application mapping for the application (systems) architecture
• Technical mapping for the technical architecture

IS modelling or business architecture software packages provide a response to the challenge of process mapping – inventory, complete list of the application portfolio, standalone applications, views and links between software, etc.

Besides initial modelling, it is essential to keep the mapping maintained over time. When no-one is in charge and with no real continuous update policy, it is not uncommon to find old mappings that prove to be obsolete just at the very time significant changes are required.

Focus on re-engineering tools

The functional and IT implementation of an architecture method(ology) is often thorny. The existing IS has to be the starting point for development towards the target information system. The IS architecture exercise should release the mapped business processes from constraints, and therefore the functional (product delivery) layer relative to lower layers in the IS architecture.

One measure of the success of an IS re-engineering process is therefore that data interchanges cease to be dependent on applications and technical constraints. In other words, a service-oriented architecture (SOA) stance is adopted, delivering standardised data interchange components that can be reused both internally and with the wider ecosystem. And with good reason, as in many cases, the mapping will have shown that business processes are not restricted to applications and are more cross-functional.

Re-engineering tools should serve to free you from technical constraints to ensure your IS is furthering the needs of business processes and company strategy, now and in future. The key steps are therefore:

• Remove applications from silos to get them to communicate with each other;
• Stop using point-to-point interfaces to eliminate any “spaghetti” effect in exchanges between applications;
• Supervise data streams to react more quickly to errors and analyse more effectively;
• Facilitate the replacement and decommissioning of applications to make your information system more agile;
• Check the impacts of changes to interfaces or applications, and avoid the vicious circle of adding layers to cover the lack of control over existing layers;
• Open your information system to partners, customers, suppliers, etc. because the reach of business processes nowadays often extends beyond the internal IS;

How Blueway can support and guide you in re-engineering your IS ?

Without detailing the technical terminology (ESB, EAI, BPM, MDM, semi-interfaces, pivot formats, etc.), our wish, through our Blueway platform, is to give you back control over data streams and provide you with a holistic picture of the data interchanges within your IS and with the outside world:

• Transport, manipulate, manage and expose data in an SOA approach;
• Model functional processes, including tasks done by people, via the user-friendly interface;
• Centralise, harmonise and unify data within master data repositories;
• Standardise data interchanges with the outside world and publish your services using an API gateway.

In addition, while Blueway is not a full IS mapping tool, we can map the data streams, data and processes that pass through our application.

We believe that the needs of the business and its people should remain the focus of any information system and underpin and guide its architecture!

!