Search
Close this search box.

Information system architecture framework and challenges

With their increasingly critical role within companies, information systems have become much more complex in recent years: successive additions of application bricks, widespread use of SaaS applications, point-to-point interfaces, new technologies, cloud or hybrid infrastructure…This makes it difficult for companies to have a global vision of their

System, and to ensure real coherence in its structuring and evolution. The risk behind the tangle of flows between applications, the disparity of data dictionaries and infrastructure choices is to make the whole unreadable, and to create a very strong inertia in changes!

And yet, with the imperatives of transformation (business, business plan, technical, relations with the ecosystem, etc.), business agility is essential. This agility translates into concrete requirements for the Information System: it’s no longer enough to design an IS for a given moment in time! The main challenge is to be able to evolve and rationalize it as new needs, constraints and technological innovations emerge…

The challenge of Information System architecture is fully in line with this context and strategic objective. A preamble to any approach is to make a clear distinction between an Information System and a Computer System! The Information System must be part of a functional vision, and more durable than the IT architecture.

Main principles and objectives of Information System architecture

The aim of IS architecture is to analyze, define and frame the evolution of information systems in line with corporate strategy, business processes and technological innovations.

The purpose of architecture is to provide a consolidated view of the IS, and to propose a coherent plan to align infrastructure, applications, IT solutions, functional modeling, business needs and corporate strategy, while taking into account the existing situation!

This approach is in line with a point of view we are convinced of at Blueway: architecture must be studied from the top down. In other words, it’s the business strategy that guides IS orientations. Business choices should not be guided by technical constraints!

Information System architecture can be broken down into 4 layers:

ic-idee-1

Business stratum

ic-idee-2

Functional stratum

ic-idee-3

Application stratum

ic-idee-4

Technical or physical stratum

How does the concept of IS architecture play out in practice?

Without getting into expert debates, in summary, the IS architect will study the four layers, the links between them and map the existing structure according to each stratum (architecture diagrams). This is an opportunity to identify both malfunctions and areas for improvement.

1st recommendation

Taking a step back

Taking strategic orientations into account, the next step is to define the roadmap and the various stages involved in moving from the current Information System to the target Information System for each of these areas. The approach is mainly “top-down”, i.e. strategic objectives and business challenges drive the other layers. There are a number of information system design methods, such as Merise, Axial, IDEF, UML, SAD etc., which can be used to take a step back from the IS architecture.

Exchanges between internal applications and with the ecosystem play an essential role in this mapping. The urbanization approach is also designed to optimize processes and information flows within the company, and to guarantee the uniqueness and reliability of data throughout its lifecycle.

So, to take a few practical examples, the IT architecture approach will enable us to answer the following questions: How are my information and data modeled? How does information circulate within my company? What data processing needs to be carried out? What malfunctions and steps need to be optimized? How can I improve my business processes and external exchanges?

2nd recommendation

Tools and software for IS architecture

There are two main categories of tools to support the IS architecture process.

The first corresponds to mapping tools for each of the layers:

  • Process mapping for business architecture
  • Functional mapping for functional architecture
  • Application mapping for application architecture
  • Technical mapping for technical architecture

IS modeling software and enterprise architecture software provide answers to the challenge of process mapping: inventory, solution portfolio inventory, application islands, views and links between software…

In addition to initial modeling, it is essential to maintain mapping over time. Without a manager, and without a real policy of continuous updating, it is common to find that old maps have become obsolete, just when it’s time to make in-depth changes!

3rd recommendation

Key criteria and functions to include in your specifications

The functional and IT implementation of the architecture method is often an arduous process. The starting point is the existing IS, which must then evolve towards the target IT infrastructure. The IS architecture approach must ensure that the mapped business processes, and therefore the business layer, are no longer constrained by the lower layers of the IS architecture.

One guarantee of success of the IS urbanization approach is therefore to no longer depend on applications and technical constraints for the circulation of information. This means adopting a SOA (Services Oriented Architecture) approach, ensuring standardized, reusable data exchange components, both internally and with your ecosystem. And with good reason: in many cases, mapping will have shown that business processes are not restricted to applications, but are cross-functional!

Information System Urbanization : Human tasks should not be forgotten!
exppert view on architecture re-engineering

Choose our Data Foundation Module to support your information system architecture

Without going into the technical terminology (Enterprise Service Bus, EAI, BPM, MDM, half-interfaces, pivot formats, etc.), our aim with the Phoenix Data Platform is to give you back control of information flows and provide you with a holistic vision of data exchanges within your IS and with the outside world:

  • Transport, manipulate, control and display data within an SOA logic
  • Model functional processes and integrate people into processes through ergonomic HMI*.
  • Centralize, harmonize and unify data within repositories
  • Industrialize external exchanges and publish your services via an API portal.

In addition, while our Phoenix data platform is not a tool for global IS mapping, we do map the flows, data and processes that pass through our application.

Démarche ESB pour urbaniser son SI

Our strengths in putting your IT environment at the service of your business processes

Splitting applications

to enable them to communicate with each other.

Break free from point-to-point interfaces

to end the spaghetti syndrome of inter-application exchanges.

Supervise flows and exchanges

to improve responsiveness to errors and analytical capacity.

Facilitate the replacement and decommissioning of applications

so that your information system becomes more agile.

Control impacts when modifying interfaces or applications

and avoid the vicious circle of adding layers because you don't control what already exists.

Open up your Information System to your partners, customers, suppliers

as business processes now very often go beyond the internal IS.

… and beyond, take advantage of the complementarity of ESB, BPM, MDM, APIM and Data Catalogue with the Phoenix platform.

At Blueway, we’re convinced that freeing yourself from technical constraints is a prerequisite for putting your Information System at the service of business processes and corporate strategy, now and in the future.

That’s why our Phoenix Data Platform unifies BPM, MDM, ESB, API Management and data mapping practices. This approach, focused on your business and human challenges, contributes to the flexibility and scalability of your IT architecture and infrastructure.

Data Platform Phoenix : DQM, MDM, BPM, ESB, Data Catalog
Would you like to discuss the challenges of urbanizing and rationalizing your information systems?

Our Enterprise Service Bus speeches

Our IS Architecture FAQ

SOA is an architectural model for structuring an application into groups of services, each performing a distinct business function and communicating via standardized protocols. Services are reusable and can be orchestrated to form complex business processes.
Data integration enables departments to share and consume information consistently and reliably. This ensures that data circulating between different services and systems is synchronized, accurate and available in real time, which is crucial to the smooth running of business processes.
Commonly used protocols and standards include SOAP (Simple Object Access Protocol), REST (Representational State Transfer), WSDL (Web Services Description Language), XML (eXtensible Markup Language) and JSON (JavaScript Object Notation).