A matter of approach

by

Leaving behind the practices that have led to an expensive, inefficient, coupled systems architecture for years, far from an efficient systems architecture, is a matter of approach.

Usually organizations base their decisions regarding the development of their information systems from a functional perspective. Each functional area has its information system, or group of information systems, trying to give an answer to the functional requirements of that functional area.

Although the functional needs of each area of the organization are important, without a global vision that coordinates these requirements, redundancies are very likely to arise. In addition, integration requirements are usually geared towards sharing information, not processes. They are usually downplayed throughout the project lifecycle. They are resolved by seeking the least impact on deadlines, without a vision for the future or impact for the organization. They are often solved in the advanced stages of construction and testing, and managed as technical requirements, without considering the functional and business value of these integration requirements.

Managing your integration requirements determines the quality of your systems map

However, the mere existence of integration requirements implies the clear symptom that there are cross-process flows, affecting several functional areas, and therefore have a business-level scope.

Therefore, it is necessary to change some habits. To begin with, even if we remain at the level of data integration, we should take into account:

  1. For an information system, integration requirements are functional requirements and therefore must be collected, documented, analyzed, and considered to focus the design along with the rest of functional requirements.
  2. Use cases must include integration requirements, and their error cases must be tested like the rest of use cases.
  3. When designing information systems and how they will address these integration requirements, consideration should be given to issues such as:
    • The policy of the organization (if it exists, of course … we will return to this matter when we deal with governance)
    • The impact of future changes on affected systems, which should be minimal or zero (look for the least coupling)
    • The use of standards for the definition of the structure and content of the data to be exchanged
  4. The definition of the solution must be perfectly and in detail documented, in a separate document, as a specification of integration solution of certain functionality, avoiding to associate it with any information system in particular, and much less any technology.

But the most important change of approach that must be undertaken, which ideally should come from ICT managers and functional experts of the organization, is to guide the architecture of the systems map of the organization to business processes. This is also the most complex change, because it places the accent on the value chain of the organization to identify the process flows that implement it through the different functional areas involved. Interoperability requirements are obtained from the analysis of these process flows, rather than traditional integration requirements. We go one step further and move from integrating data, to sharing business processes. In this way we not only get the benefits of reducing time to market, increasing agility and flexibility in the value chain, but also increase reusability and reduce the costs of IT projects.

A mere trifle…

The SOA strategy requires a change of focus with a number of key factors

So let’s stick to two conclusions:

  • Integration requirements should be taken more seriously, as seriously as any other functional requirement of an information system
  • The approach of the organization must change towards the business processes, obtaining the integration requirements from their analysis, with a broader scope to achieve the implementation of such processes through reusable and standards-based business services.

BPM and EDA have a lot to say in this change of approach. The former, to model and analyze business processes. The latter, to introduce the real-time availability of business services and the information they send.

Te puede interesar

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Follow me on social media

Share This