The application of a so-called Enterprise Architecture plan (EA) or framework system is a vital tool in the efficient operation of any organization or company. It presents, in a comprehensible form, exactly how and what values are generated by a company’s or enterprise’s resources (processes, assets, data, human resources etc.), and how they are linked to each other. As such, EA is a framework system that identifies the most critical components from the point of view of the operation of the company, furthermore, how these components are connected to each other. (Perhaps the easiest way to visualize this is to think of an organizational chart and the connections between individual organizational units.) EA areas:

• Business architecture: the most important field of EA, that describes how the important business processes function, and through which processes, using which resources and data, and within which regulatory frameworks business objectives are realized.  IT’s primary task is to support the realization of business processes. To do this we use software/apps, which in general adjust to organizational changes with a slight lag, or they try to satisfy arising demands. As a consequence, software solutions used in the organization undergo continuous transformations, it is impossible to ever reach a ‘this is finally the finished’ state.
• Application architecture: a plan showing the connection between supporting systems/applications.
• Data architecture: outlines data generated in the course of operation or necessary for the operation, and their interconnections. It is easy to get an overview of how the quality of apps and data influence to a significant extent the operation and profitability.
• Naturally, applications need to be run somewhere and data need to be stored somewhere, and the systems have to be connected with something. Related plans and descriptions are formulated in technology architecture or platform architecture.

In an ideal world, the four areas listed above are implemented and developed in sync with each other, with due attention to expectations and possibilities. This would be the ultimate modality of architecture planning. Unfortunately, it rarely happens like this because typically, implementing change in the current state only comes into focus when something is already working badly. In general, the introduction of new functions most often creates the opportunity to implement architecture planning. Thus, the appropriate work process is concluded logically from the abovementioned:

1. it is important to clarify the most important business objectives;
2. what existing data are at our disposal;
3. what are the connections between these data;
4. what are the local circumstances of the existing application;
5. and which technological stack does the system have to be incorporated with.

The more accurately we can define these in agreement with the client, the better the end result will be. In practice, suppliers of IT solutions mainly sell or develop technology elements and they only address the above issues relatively rarely. If the customer is not smart enough in understanding and managing the above, then it should be handled by the solution supplier. If neither party handles this issue correctly, then the end-result will be cause for disappointment. We at INNObyte make every effort to ensure the greatest possible understanding between satisfying business needs and technological implementation. As László Blénessy, consultant to the CEO at INNObyte, put it (HERE): “Any company can have talented developers, but there are few who know how to bring these two worlds closer to each other. Success will come to those who can precisely identify their clients’ needs.”