This text has been translated from Google Translate.
In IT, we have borrowed a lot of terms from the construction industry. For example, we will distinguish the MOA - project management, from the MOE - project management. The first includes the architects and engineers, the second the journeymen and the works manager. Well in IT we find them. The MOA will define the user's needs, the MOE will implement the solution.
And the Architect in all this?
Already, he will think about setting the information systems on a business need. He's going to take the Merise method and break the business down into subsystems. He will make sure that we have cut things out in an intelligent and coherent way.
And then once we have deployed an application, it surely has dependencies. It probably takes place in a business context, called a domain for example. There may be two parallel versions. You may be migrating part of the business from one software to another (from SAP to OSS for example). And this project will last several months. It will surely be necessary to think about the training of users in a business context.
If you are in an international company, you will surely have to think about a phased deployment. Does the software product work in every environment?
In short, the IT Architect is a technical role that is outside the product or application team. He is not yet exactly in IT Governance but contributes greatly to it.
We talked about the role of the architect with Julien who is CTO at Zénika and you will see that it is not an accessible profession. It requires a lot of business knowledge and soft skills to navigate through a complex corporate organization chart.
Being a consultant and working in different companies is clearly a good way to become an Architect. Your company surely has a collective authority so that architecture decisions are made in a less top-down manner. Contributing to this working group will help you access this profession.