In accordance with the long existing friendship between the Association of Enterprise Architects and the Atoll Group, Atoll was invited to present on the monthly gathering of the Hungarian chapter of the AEA.

Atoll was the first ever presenter on these monthly occasions of the Association and is following the life of the chapter ever since. This time Atoll has asked one of their major local client to share their experience with the SAMU enterprise architecture repository.

The presentation took place at the Telekom, who kindly offered their location for the event. Appearing on the stage was no other than Tamás Nacsák, the Chief Enterprise Architect at Telekom Hungary, and Gábor Vincellér, the development manager of the SAMU product.

The title of their presentation was:

Application catalog or knowledge base?

In the beginning of the presentation Tamás pointed out, that the most important goal with using a common repository is to

Turn the inherent knowledge of the organization into useful information, that serves the current business goals of the organization.

Over the course of the event, Tamás and Gábor described the way the architecture organization works in Telekom, how the different levels of architecture boards are organized and operate, and how architecture modelling fits in the environment.

They pointed out that the most important decision in the beginning was deciding on the structure of the repository. Due to the nature of the business the core structure is based upon the eTOM Shared information and Data model (SID). Even though the model is very extensive and seems quite straightforward, it is not as easy to identify the elements of an architecture as one would think. To mention one such dilemma, the boundaries and definitions of an Application or Software are vague at times, and require some agreements for categorizing architecture elements.

Tamás pointed out, the most convincing value proposition supporting the creation of the architecture repository, was the transparency and traceability it creates for the interdependent complex services provided by Telekom. Since the most important in Telco is to keep the operation up and running, the primary benefactors from the system are from the OSS (NT) field.

To achieve this transparency however, huge efforts were put into mapping the Customer Facing Services (CFSs) and the Resource Facing Services (RFSs) that make up the product service trees. Due to the flexible nature of the repository, it was not difficult to map the persons involved in the services to be attached to each node. This allows for personalized view for each service manager of the services they are responsible for, along with their dependencies. This capability is great for creating impact analysis before a change as well as for tracing problems in production.

Integration was pointed out to be a key feature of the SAMU. At the moment the SAMU is already connected to ActiveDirectory interfaces, and the Signavio process modelling tool, as well as an important addition to the service catalogs detailed above, the HP Service manager.

Integration of the CMDB with the architecture provides the most valuable insight to the operational environment.

As a result of the CMDB integration the service trees consisting of CFSs, RFSs are directly linked to the underlying physical resources. This allows real-time monitoring of the state of the operation, and results in faster reaction times.

For the future of the architecture repository it was pointed out that the most important goal is to extend it’s reach. Involve as many of the affected stakeholders as possible, get them to know and understand the value of the repository. This establishes a more advanced culture of the architecture management throughout the organization.

As the stakeholders gain a better insight to the way the architecture works, they will be able to express their actual needs better, and the model will grow organically to reflect the actual needs.

As one of the most important takeaways Tamás emphasized a few points.

Vendor and customer should work for the same goals

Monitor  delivered value

EA leader is a business leader!

Even though it sounds trivial, the companies introducing EA tools and their vendors should work together to find the best modelling practices for the company. EA tools are just too complicated to be deployed out of the box.

As another point he mentioned, that the actual business value created by a repository should always be considered. It’s not supposed to be an art form, but a practical inventory. Modeling something just for the sake of having a complete model will not create business value!

Finally we were reminded of the importance of the EA leadership,  and how the Chhief Enterprise Architect should find it’s rightful way into the ranks of company management.