The Zingoolarity App

The Zingoolarity app (whose name is an artificial synonym for singularity, the place where everything comes together in one point due to gravity), is in essence a standalone web service, which can be run on any cloud and needs only a MariaDB or MySQL database as a dependency (to store the data in a structured way).

It is written in Go and is provided under an open source license without any cost involved.

It utilities pure Go and its libraries, HTML and a little bit of Javascript, avoiding the use of complex and heavy weight frameworks.

This is because one of one major design goal: Responsiveness (Response is instantaneous).

Therefore the GUI is clean and simple ... not "fancy".

The Zingoolarity app implements the following objects:

Users

Zingoolarity allows you to maintain users, which can login, use the Zingoolarity app and logoff again (or stay in login state, which your browser automatically remembers).
Users can be either created by an admin and be auto-informed of their new account by email, or they can self-register by providing their name, email address and their details.
Self-registered users are disabled by default and need to be activated by an admin of your Zingoolarity installation.
Existing users can also recover their account information by providing their email address (initially or in case they misplaced the necessary login information).
Zingoolarity does not operate with usernames+passwords; each user receives a 32 character long personal secret certificate by email, which can be used to login and which is automatically remembered by your browser.
If a user suspects that his or her account has been compromized, they can recertify their account and thereby create a new random secret certificate (which they can again recover by email).
Users can be normal users (read-only access), editors (write access) or admins (user management + configuration management).

Users also represent resources in the broader context of Zingoolarity (they can take responsibility for roadmap items or become part of a team with a certain role).

Timings

Zingoolarity allows you to maintain timings, which represent slots in a timeline, on different granularity levels.
You can for example create 3 different timelines for the current and the next year, one on years quarter level, one on month level and one on week level.
These timelines are used to place roadmap items on one of the pre-defined timelines and along with the duration attribute, define the planned end of a roadmap item.

Types

Zingoolarity allows you to optionally maintain types, which represent categories of topics.

This helps to establish a certain terminology in your company.

You can for example create the following types ...

• Lane
• Domain
• Product

... to structure your business domain map.
You could also created types like ...

• Unit
• Department
• Team

... to represent the line organization of your company.

By default (to reduce complexity), types are not used (except for the micro-website feature explained at the end of this guide).
You just create topics within topics to model your structures and optionally add types later-on incrementally.

States

Zingoolarity allows you to maintain states, which represent the different states a roadmap item can be in (or the item of a Kanban board).

By default, the following states are available out-of-the-box (which is some kind of best practice collected in different projects with different companies, but feel free to create your own state model):

States are associated with colors.
These colors are a simple instrument for making roadmap, Kanban or context views easily understandable.

Roles

Zingoolarity allows you to maintain a reference list of typical roles needed in your teams.
By default, the following roles are available out-of-the-box (based on a simple model of a product organization, but again, feel free to create your own role model):

Capabilities

Zingoolarity allows you to maintain a list of business capabilities in the structure of a classic business domain map (lane, domain, product), which can be associated initially with any level of your product organization (to assign responsibility in the first step).

The association with a topic represents the reponsibility by a lane, a domain or a product team during the initial build-up phase of your work organization (by definition, there can only be one responsible team).

In the second step, capabilities are intersected with applications and products and assigned a lifecycle state, which lays the foundation for a target architecture map.

Applications

Zingoolarity allows you to maintain a list of applications, which can be associated initially with one responsible person ("owner") and with any level of your product organization (to assign responsibility in the first step).

An application is an architectural building block and can represent a true software application (either a service or something with a user interface), an internal or external service to be delivered (e.g. Governance, Helpdesk, etc), a platform on which other teams can build their applications (e.g. Microsoft Dynamics) or a module inside of a larger platform (e.g. SAP Material Management (MM)).

The association with a topic represents the reponsibility by a lane, a domain or a product team during the initial build-up phase of your work organization (by definition, there can only be one responsible team).

An application also usually has an application owner, who is the main responsible person for the application and works in a product team (and is the ultimate specialist for this application).

Finally, an application can have a direct lifecycle status, from being part of the target architecture up to the end-of-life decommissioned state.

Categories

Categories are an optional way of structuring your applications into different kinds.

Usually there are at least something like business applications, foundation applications (which provide technical building blocks for business applications) and services.

Cycles

Zingoolarity allows you to maintain cycles, which represent the different lifecycle states an application or of a usage of an application to implement a capability.

By default, the following cycles are available out-of-the-box (which is some kind of best practice collected in different projects with different companies, but feel free to create your own cycle model):

Cycles are associated with colors.
These colors are a simple instrument for making your target architecture map easily understandable.

Periods

Zingoolarity allows you to maintain periods for budgeting and cost control.
This is an additional time dimension for managing the commercial aspects of your organizations.

By default, there are two example years available, each containing 12 months.
But again, feel free to create your own budgeting period model.

Forms

Zingoolarity allows you to define forms, which can be used in the context of other objects (at the moment, this is only used by applications).

Forms can represent questionnaires or checklists and are a collection of 1..N input fields (single line, multiple line, select box, etc).

Form definition and data is stored in a unified format (ZML), so that you can evolve and further extend your forms without affecting existing forms first.
The new version of the form can later be applied to all existing forms, when the new version has reached maturity.

In a future version of Zingoolarity, forms will become a standard part of all major objects.

Topics

Topics are the main item in Zingoolarity, which can represent items on a roadmap or a Kanban board, units in an organization and at the same time can optionally contain a bunch of people representing a team associated with the topic.

With this approach, you can have everything from product teams, project teams or chapters which assign their people to products or projects in certain roles.

They could also represent work items or really anything else.

Each topic has a couple of simple attributes:

Actions

Actions in Zingoolarity are taken in the context of a topic.
They represent any activitity performed or relevant information shared by a user for this topic.
An action can optionally contain an attachment (e.g. a concept document), if it cannot be shared by reference (as an URL).
You can understand actions as a chronological list of activities performed to complete the topic.

Teams

Teams in Zingoolarity are assignments of users to a topic in a certain role and with a certain FTE (full time equivalent).
Teams can be assembled for everthing: a line organizational unit, a work organizational unit (e.g. a domain or a product) or a work item (a project, an initiative, an epic etc).

Links

Links in Zingoolarity are relations between topics (in addition to the primary relation of parentship).
Links can represent simple things as dependencies between work items.
But they can also represent the relation between two different maps (e.g. between projects and strategic goals).
Links are always bi-directionally visible (you can view and edit them from both sides of the relation).

Usages

Usages in Zingoolarity represent intersections of business capabilities, technical applications and parts of your product map (usually product teams).
This allows you to map all your existing applications to business capabilities and assign them into the responsibility of product teams.
At the same time you can add different applications in different lifecycle states, so that you can clearly document applications which are currently used and which will be used in the future.
Each intersection has a maturity level and a description, so that you can easily create a structured data pool which automatically visualizes your architecture target map.

Matches

Matches in Zingoolarity represent a special relation between budget topics and invoice topics, additionally specifying the period to which the the relation belongs.
This allows you to establish a dynamic budget control process by creating budgets on whatever organization you deem necessary (e.g. line organization, products or projects).
When you receive a real spending of the budget money (e.g. an invoice from a supplier or a monthly booking salary record of HR), you simply create an additional topic representing this (as one process step) and then matching these spendings to your budgets by mapping them to the correct periods (as a second process step) and setting the amount in currency.
The maps containing the budget will automatically show planned and as-is numbers, which provides a simple but tremendously effective tool to control your cost.

Views (or View Modes)

Views in Zingoolarity are the visualization of topics in various ways.
Based on practical experience, exactly three different views are available (to keep things simple):

• 1. Roadmap
  Visualizing topics on a certain timeline, thus representing a roadmap.
  Topics are represented by bars of different length, mapped on the configured timeline of the parent topic.
  This is the preferred view for roadmap planning and review.
• 2. Kanbanboard
  Visualizing topics in state columns, thus representing a Kanban board.
  Topics are automatically placed into state columns.
  This is the preferred view for to-do lists.
• 3. Contextmap
  Visualizing topics in nested boxes, mapped out horizontally and vertically.
  This is the preferred view for hierarchical structures or orgcharts.

As topics in Zingoolarity can contain other topics, any view in Zingoolarity is drillable by clicking on the name of a topic.

By that, you can for example create a topic Implementation Phase in the context of your project, focus on it and create more topics in the context of the implementation phase, which need to be completed to fully complete the implementation phase.

These sub-roadmaps can have the same timeline as the roadmap above, or they can have a different start and end, or they can even have a different timeline level (thus making it possible to drill from a monthly roadmap to a weekly sub-roadmap).

In Roadmap and Kanban view, topics on a map, which do not have a timing (yet), are automatically shown in the left-most column (undefined), which can be seen as a kind of backlog.

These three views are essential in Zingoolarity.
Everything is created and edited in the context of a view.
You can easily navigate between the different levels by focusing on items (drill down) or using the breadcrumb on top of the screen, which shows the path up (drill up).
You can even open or close topics to view or hide their content (like a directory in a file browser, but with the individual dynamic formatting of the selected view).

This allows you to nest Kanban boards within Kanban boards, roadmaps within organizational units, dynamically add Kanban boards to roadmap items and much more.

It is one of the key strength of Zingoolarity, to provide this kind of iterative and incremental flexibility.

Summary

The additional summary view of Zingoolarity (which is read-only) allows you to view a topic tree with all relevant information, including the actions for every topic.

This is a good way to provide a status report in a meeting or a call, as it shows the relevant information (assuming you use the actions to log relevant events).

Daily News

Zingoolarity allows every user to optionally subscribe to the daily news.

This is an automatically generated email once per day, which contains all the new actions of that day in all topics.

It can be easily digested to keep up with the progress of your roadmap (assuming you use the actions to log relevant events).

Export

Zingoolarity provides the capability to export and (re-) import all available data objects.

Exports are being performed in ZML format, which is a simplified tag-based format (much like HTML) and which can also be edited with a simple text editor before (re-) importing.

Here is an example of a ZML file containing one role object:

[role]
[id]cpo[/id]
[name]CPO[/name]
[detail]The chief product owner steers the entire product, platform and initiative portfolio.[/detail]
[active]1[/active]
[lead]1[/lead]
[sort]0[/sort]
[/role]

Bookmarks

Zingoolarity allows you to add any number of topics to your personal bookmark list.

This provides quick pick capabilities for your most-used topics (e.g. the projects you work on, your personal workspace, etc).

This is a convenience feature.

Capability Map

Based on the structured list of capabilities, Zingoolarity allows you to automatically generate a business capability map to visualize and support your business process improvement.

It can also automatically show usages, which transforms your business capability map into a target architecture map.