Sparx Services CE: The twelve commandments of EAM(PresseBox) (Vienna, )
When Michael Bald, specialist for Enterprise Architecture Management (EAM), talks about his favourite topic, you immediately notice that it is a matter close to his heart: "To implement EAM in a company, you need clear guidelines and a consistent concept. It is quite clear that the business architecture must always be the starting point. This is the only way to operationalize the strategy, which leads to the desired improved internal communication and the reduction of time-to-market and costs (the TCO - Total Cost of Ownership)".
Enterprise Architect uses Bald in this approach to improve communication and clarify responsibilities: "Especially at the management level, responsibility for the decisions made must also be taken. This is where Enterprise Architect helps me to convey the most important relationships in an understandable, graphic language! The big advantage is that the graphic representation of the business is also easy to understand and sufficiently detailed for management".
Enterprise Architect supports EAM very well
The EAM specialist appreciates the flexibility of Enterprise Architect and the many technologies contained in the tool that support EAM. This tool can be used to operate all levels, but it is important not to start work from the application level. Peter Lieber, founder of Sparx Services CE: "We are proud that Michael Bald is using Enterprise Architect as the central tool in the EAM process. Clear communication in the EAM process is ultimately the basis for the success of a project. As a partner company of Sparx Systems, we have the competence and expertise in the targeted use of Enterprise Architect. In addition to the tool, method, experience and (modelling) languages are the sustainable starting points for the successful establishment of EAM."
Accurately survey business services
Bald pleads for the EAM to be based on several standards: TOGAF, ArchiMate, BPMN and UML combined in the right way would bring the greatest benefit. At the start of the procedure, it is important to record and precisely describe the business services (not to be confused with the business capabilities) and their responsibilities that are provided in the company. ArchiMate and Enterprise Architect are used for this, and the company's business service landscape is created. In ArchiMate the business services are recorded (Who does what?), Enterprise Architect, on the other hand, is used for business process mapping (How and when is the business service provided?). If the business services are known, then the business processes of the business architecture can be modelled LIVE in Enterprise Architect with the responsible persons. Bald knows from his own experience that even untrained people can complete this task after one or two weeks of training.
Adapting business services to new requirements
Based on the status quo that has now been established, it is easy to work on changing the business services. This requires close coordination with the management in order to define them in a way that is appropriate for the target group. "Ultimately, the management is responsible for the newly defined business services or other value-adding activities, so precise coordination and approval is essential," says Bald.
Once agreement has been reached on the services, the next step is to build the business architecture on this. Since this architecture supports management in its work, it is important to map the specific information needs of the various stakeholders. ArchiMate is used for this in conjunction with the view concept defined in TOGAF. Since both standards come from the Open Group, they model the enterprise architecture in the four TOGAF architecture domains of business, application, data and technology architecture. This is combined with the Business, Application and Technology layers defined in Archimate. All domains are connected step by step, always following the motto "Business Architecture FIRST!
The model is the truth
Finally, the EAM specialist would like to see the awareness, that the model, the Digital Twin of Organisation (DTO), is ultimately the central source of information for EAM projects. "In the building authority it is clear to everyone involved that the only binding answer to controversial questions lies in the architectural plans. For me, this applies just as much to EAM information as it does to business service landscapes and business processes, which are also very complex and where the truth defined in the definition process must be found in the models".
The twelve Commandments of EAM
1) Don't define a metamodel first, but start with architecture standards and restrict these standards to your needs
2) For EAM several standards are needed. So use the languages TOGAF, ArchiMate, BPMN and UML combined
3) ALWAYS start with the business architecture
4) In the beginning there are always the Business Services (TOGAF & ArchiMate), which are provided by people
5) Define a person for each business service who will also take responsibility for it - this is the only way to operationalize the strategy
6) The business architecture takes precedence over the application architecture
7) The business services are recorded by the architecture team to relieve and support the business (the departments).
8) Always concentrate on the business services. Put capability or function maps on the back or leave them out altogether, they are castles in the air!
9) Use LIVE Business Architecture Modeling to talk to the Business Service Owners: After each meeting there is an approved architecture diagram
10) TOGAF and ArchiMate are your friends, use them
11) Also show the upper management levels the business model (DTO), as everything is very well represented here
12) Set up EAM as a business service independent of IT