Architecture Framework: Translating Business Needs into Custom ARIS Connect Portal Views

Hi, very interesting topic — happy to exchange thoughts on this.

Let me go through the layers in the same order as in your post.

1. Stakeholders

Of course, a lot depends on the existing BPM governance cycle, but if we simplify it significantly, I would say that the portal is definitely not an operational-management layer.

It is also important to recognize that, in reality, the portal is usually not a particularly “crowded” place. People use a tool only when it provides practical value.

For operational-level stakeholders, who often lack the training or time to read complex artifacts such as process models, simpler management tools are usually more effective: job descriptions, work instructions, procedures, etc.

Often, job descriptions are either part of the corporate employee portal, where employees can access them directly from their profile, or formally signed as hard copies.

At the same time, a job description can be derived from many ARIS models and generated automatically by a script. In that case, portal navigation itself is not particularly important for the operational user. For example, in our projects we sometimes include hyperlinks from the generated job description to the respective process models in ARIS Connect, but this is more of a supporting feature—something a user can follow if they need to understand exactly where they participate in the process.

The same applies to work instructions: they usually describe operations in much more detail than you would normally find at the process-model level.

Middle management needs are different. They usually need a consolidated view of the entire process. This is often covered by an SOP or similar process document, which again is a derivative artifact. You cannot realistically build that understanding by opening and navigating through ten or twenty separate diagrams.

So here again, the portal itself is not necessarily the primary management instrument.

As for senior management, they are usually not regular portal users at all. The relevant information reaches them through presentations, dashboards — very often external rather than ARIS-native ones — management reports, KPI reviews, and similar formats.

2. Access Control & Governance

This is where ARIS can become rather painful.

In practice, full access-right administration requires someone who understands both the system and the repository architecture—essentially an ARIS architect or someone very close to that profile. And such people are normally a scarce resource. Because of this, access-management concepts are often simplified considerably in real projects.

Another complication arises when IT, especially Information Security, realizes that responsibility for granting access to business content is effectively shifting from IT to a business function. The alternative is for IT to maintain its own ARIS resource who understands the repository structure, architecture, filters, permissions, etc. But maintaining such expertise purely for access administration can be quite expensive.

3. Presentation & Navigation

This is partly related to my first point.

In my experience, you need far less deep portal customization than it may initially seem. What matters much more is proper training. No matter how well the portal is customized, if users are not trained properly — and I do not mean training on “how to use the portal”, but rather how to work with the business knowledge available to them, of which the portal is only one delivery channel — they simply will not use it.

Good navigation matters, of course, but usability alone doesn't drive adoption.

4. Technical Configuration Engine

Here I may not fully understand what you mean by XML customization.

Most of the configuration we normally need can be done either through drag-and-drop configuration, for example on the home page, or through modification sets. From my perspective, the more important technical topics are often things like seamless user access—for example, LDAP + Kerberos or SAML + SCIM—keeping navigation as simple as possible, and, very importantly, ensuring good portal performance and access.

Hi! Thanks so much for taking the time to share your perspective.I really appreciate the pragmatic angle you brought to this. Getting these kinds of real-world implementation insights is incredibly valuable, especially when connecting high-level architectural concepts to day-to-day operations.

You hit on some great points about the gap between what tools can do and how businesses actually adopt them:

1. Generated Artifacts vs. Portal Usage (Layer 1): You're completely right about portal traffic. Frontline teams and executives rarely spend their day clicking through process models. Pushing generated artifacts like automated Job Descriptions or SOPs (via ARIS Report scripts) directly into HR systems or corporate intranets makes way more sense, with ARIS links acting as a back-up for anyone needing deep context.

2.Governance Friction (Layer 2): Spot on about the administrative headache. Managing Method Filters and database privileges takes deep repository expertise, which almost always triggers that familiar tug-of-war between IT security and business process owners over who actually owns access management.

3. Adoption & Change Management (Layer 3): A great reality check that UI customization is just an enabler. If people aren't trained on how to actually interpret and use business process knowledge in their daily work, even the cleanest navigation layout won't drive long-term usage.

4. SSO & Performance (Layer 4): Fully agree on the basics coming first seamless SSO (SAML/SCIM/LDAP) and solid portal performance matter far more to end users. My focus on XML customization (view.xml and ItemSetsinside Modification Sets) was mainly aimed at those niche cases where out-of-the-box layouts just don't meet specific role requirements.

Thanks again for opening up this discussion :)