ARIS: Level Based modeling of IS Functions (IT Capabilities). Taming the complexity:

ARIS defines IS Functions (Capability in ARIS 7.1) as a generic IT resource that supports a function within a process. (I truly love the way IDS has defined this tricky aspect, which many manager in IT are not able to capture immediately).

For example, if we consider an application such as Microsoft EPM Project server, which support “Project Management” capability.

However, Project Management function capability is at a higher solution level, and it is more interesting to identify the activities/components of the Project Management process such as resource management, Project execution, Project risk management and so on.

It would also be interesting to identify what features of the just mentioned activities EPM supports. For example, features of the activity “Resource Management” such as Time sheeting, allocation of resources, Management of resource information, assignment of resources, Effort tracking and so on. I would recommend a breakdown of capabilities to this level of detail is needed for any decent level of architecture analysis.

Level 1 (Component level): Project Management

Level 2 (Activity/ Component level): Resource Management

Level 3 (Features level): Time sheeting, allocation of resources,,,,

Note that there can be a need to breakdown the level of details into further details, level 4 in this case. By this hierarchical approach, link IT applications and their capabilities. The level of detail of the capabilities can be captured in an attribute.

ARIS - IAF: Business / Business Information services objects rationalization

I have a theory. When I propose a solution, and if someone poses a question on that solution for which I do not have an answer, I deem my solution as flawed.

I am in-charge of defining and deploying IAF using ARIS in the organization I work for. A question was posed to me, as to why "Business service" and "Business information service" use different objects when both represent the service notion of same business activity, but from different aspects. In fact "BS" and its partner "BIS" also have a one to one mapping.

BS captures all aspects from the business perspective and BIS filters the same purely to an information aspect.

From an ARIS modeling point of view, I find it best to reuse the same object to capture BS and its BIS but to use different views (model type) to capture the relevant aspect's artifacts.

For example, service object name "Hunt rabbits" in model type Business service interaction model, captures interaction with other business services such as “sell rabbits” and “cut rabbits”, with inputs such as firearm, transports, roles such as hunter, butcher, vendor and so on. The same service object “Hunt rabbits", in the model type “Business information service interaction model” captures the information aspects of hunting rabbits such as season, hunter skill level, market price of rabbit meat and so on.

Any comments or am I missing something?

ARIS - IAF: Differentiating of concerns between the IS/IT and Technology infrastructure aspect areas

I notice in many situations that physical hardware infrastructure artifacts are mixed with and the IS/IT aspect architecture views. I agree with the need in some situations where there is an interest to know the actual instance of the infrastructure such as a server. But for large architecture overview models, mixing aspect areas is not a good idea as it posses governance issues and overkill of information with too many objects scattered on the model.

This is similar to differentiating the aspects of IS/IT and infrastructure in IAF.

In IS/IT architecture overview model (IAF’s IS/IT logical and physical components), architects are more interested in interactions between various IS/IT components and not the infrastructure which supports it. Usually, the lead IT/Solution architect will be the owner of this view.

A technology infrastructure topology model captures the TI component’s interactions and where they are located. The infrastructure folks would be the governor of this view.

There should be a cross reference between the 2 aspect areas, to capture the links between an application and infrastructure supporting them. Use of contracts is very critical to understand dependencies.

I find that this solution of having an aspect area centric modeling by the differentiating the aspect concerns eases the clustering of models and also solving the tricky issue of model governance.

Hope I made sense.