ArchiMate Modeling in Practice - Defining the application landscape


Subscribe
Bas van Gils & Sven van Dijk
Posted by Bas van Gils & Sven van Dijk on Oct 21, 2013

Enterprise Architecture, ArchiMate

Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.

The team is in full swing now, very much aware of the fact that ‘the pressure is on’. The reference models are in a “good enough” form at the moment, and some of the grumbling from management seems to be fading away. Through informal channels, the team has learned that part of the frustration seems to come from the fact that an audit (“quick scan”) by an external party has resulted in advise to management to “speed things up a notch”. So much for careful planning!

Working closely with her sponsor, Brenda is attempting to buy the team as much time as possible to do the actual work. She has successfully pitched the idea of including a security analysis in the solution models that she has promised. It may mean extra work, but it will be worth it if this is the final push for acceptance of the results from weeks of modeling by the team.

Modeling the application landscapeModeling the application landscape

In order to kick-start the modeling of the actual application landscape, Brenda has developed a simple poster to guide her team. Her mantra is “model as little as possible, but not less”.

Starting with the reference models that have been developed by the team, her goal is to make sure the team first understands at a high-level which capabilities are supported by which functions / data in the system landscape, and then do a mapping on the actual components. The mapping on capabilities will be done as an exercise on the whiteboard and is not a formal deliverable at this point due to timing issues. The team makes a note to pick this up later. Modeling the landscape also include clear insights in how data will move from one component to the next. This will most likely be the hard part to define, given that the team wants to use an MDM-based solution. However, everyone is confident that there will be a lot of value add in the long run, so the team quickly goes to work.

As a final word of guidance, Brenda makes sure that everyone understands that (a) this has to be done quickly, and re-use of the reference models will make that possible, and (b) next week will be all about developing a detailed model that shows how a single capability is supported by the newly developed application landscape.

The target architecture for the application landscape

At this point in the process, the team really starts to benefit from all the preliminary work. The different pieces of the puzzle can now be connected and transformed into a solid and future proof target architecture for the BriteLite organization. The MDM studies and patterns, and the reference application models have been documented consistently in the ArchiMate language, and moreover in a single repository which is an integral part of BriteLite’s EA tooling, BiZZdesign Enterprise Studio. This means that creating models for the target architecture is “merely” a matter of reusing and generating new diagrams based on existing information.

The view below is an example that illustrates this point. It visualizes how the core applications in the landscape are aligned based on the co-existence MDM pattern. The applications share functions and data around customer management, order management, as well as inventory management. The data in the individual source systems is consolidated and managed by the MDM hub. One of the key functions of the MDM hub is to maintain the “golden record” for each of the shared data objects. The team uses a “service oriented” approach. Application services represent “useful” automated functionality for users (human users, or other objects in the application landscape) of a system. Translating this idea to the target application architecture for BriteLite, the MDM hub realizes a “data mastering service” that can be used by the transaction systems. To make this picture even more specific, and to put a focus on what data is mastered by the MDM hub, three “instantiations” of a data mastering service are modeled,  by type of data. 

 View visualizing how core applications in the landscape are aligned

The team also works on the target technology architecture. Team members use the objects from the technology layer in ArchiMate to create diagrams that provide insight on the deployment perspective of the target architecture. The example below shows how ESB technology is incorporated in the infrastructure to support the actual exchange of data between the components, including the core applications, as well as the MDM hub.

 Diagram using objects of Archimate technology layer to provide deployment insights

 

As the development of the target architecture progresses, it is time to start thinking about the next challenge: how to get there from where we are today? In other words, a next task for the team is to start thinking about an implementation roadmap. So stay tuned for the next episode!

 

Delivering Business Outcome with TOGAF and ArchiMate

SUBSCRIBE TO BIZZDESIGN'S BLOG

Join 10.000+ others! Get BiZZdesign's latest articles straight
to your inbox. Enter your email address below:

 

Subscribe to Email Updates

comments powered by Disqus