View source for BestPractices:Enterprise architect information

=== Processes ===
[[File:EAI - 1.png|frameless|329x329px]]

The first axis of information is the Processes – you can define the Steps of the process and the Stakeholder’s motivation for having this process in the first place.

=== Information ===
[[File:EAI - 2.png|frameless|338x338px]]

The second axis of EA-information is Information – here we can catch and see what the business call things – the catalog term – what states the catalog terms can have – according to the business. We can also define how this catalog term is implemented with classes or attributes. If we are 100% DDD compliant (as defined by Eric Evans book DDD – Domain Driven Design) the Catalog terms will have the exact same names as our classes. You will find that this is very good idea and it gives you the ubiquitous language between systems and business that everyone wants but very few manage to get and keep over time.

Having a separation between Catalog terms and Classes is an acceptable solution that enables both DDD implementations and also more traditional approaches.

When the language in the business and in the IT- systems are not ubiquitous this separation of axis enables us to define the lexicon between the two languages.

=== Actors ===
[[File:EAI - 3.png|frameless|430x430px]]

The Actors are the named Roles of the Business – they may have motivation to engage in processes and they may have user stories for specific steps of processes.

=== Applications ===
[[File:EAI - 5.png|frameless|434x434px]]

The fourth axis of information is Applications – we need to know the tools of the business. It is important to know the tools and in the end what information the tools contain in order answer questions about what will happen if an application is temporarily down or needs to be replaced.

The applications are one thing – but most applications are divided into modules or application parts. This is also defined in the screen above.

If you want to detail the use cases for these tools you can do so by defining ViewModels in AppComplete – the ViewModels will not only exactly explain what information that is used for that use case but also enables you to prototype or develop user interfaces to are suitable for the task at hand.

=== Infrastructure ===
[[File:EAI - 4.png|frameless|437x437px]]

The fifth axis of information in the AppComplete – EA-Information tool is Infrastructure.

Here we can define infrastructure nodes that our applications or part of our applications depend upon.

Having this information documented makes it easy to answer questions like “can we de-commission Server X or not”. And  questions like “I need to replace the router on floor 5, can I do it Thursday?” can be answered by tracking back what applications depend on it, then find what processes steps that use the applications and in the end find the Actors and Stakeholders involved.

=== Process steps ===
[[File:EAI - 6.png|frameless|421x421px]]

The process steps are really the core of the EA-information and as such you can explain in detail what the inputs and outputs are – you can also express if the step needs some information from another source than the input – we call this Resources.

This information is expressed with the Catalog Terms so you get full cross reference between all the axis in the EA-Information.

=== Information at your fingertips ===

The EA-Information shows up in the other views of AppComplete. You can show single steps in Process diagrams:

[[File:EAI - 7.png|frameless|479x479px]]

And Catalog Terms show up in the classes in Class Diagrams

[[File:EAI - 8.png|frameless|487x487px]]

And Cross references are available in the Auto-Diagrams

[[File:EAI - 9.png|frameless|373x373px]]