Here is an interesting thought of a colleague yesterday (Thomas Vermassen – Lead Architect ORES) on documenting IT systems:
You have basically two strategies for keeping your Enterprise Architecture knowledge under control.
The first one is to capitalize on people. If your organization is stable enough you can assign clear responsibilities and you should be able to find the right information by finding the right person.
The second one is to capitalize on documentation. Through deliverables you make sure everything is described as it should be. This is most suitable if you have a high collaborators turnover like when you work with a lot of sub-contractors.
The ideal world is probably to have both.
I’m a deliverable minded person and I so I tend to prefer the second one. I value information sharing as it often avoids job protection and silo thinking. The notion of deliverable is also linked to another value that I like : personal contribution.
Also when the architecture is complex I don’t see how you can just book a meeting with someone in oder for him to explain you the 100 business processes in scope. That must be why clever people write books……
Also seen in “The Process of Software Architecting 1st Edition” by Peter Eeles, Peter Cripps…
In this diagram I mapped all business requirements to the corresponding business actors. At the top we find the requirements families. The objective was to determine clusters of requirements that can be regrouped in target use cases (more than 50 in this case).
I have documented the method in this post : requirements matrix in archimate.
Critical flows show how the information flows from user to system and from system to system.
Structuring and graphically representing requirements can be challenging for large projects. Today I figured out how to draw the equivalent of several pages in excel into one single archimate diagram.
The requirements are structured in 3 columns : requirement family, description and concerned stakeholders.
Using archimate I drew actors corresponding to stakeholders vertically, as a kind of first column. Then I drew all requirements families at the top as a kind of first line by using xxx of the archimate motivation extension.
Requirements can then be represented as a kind of cell in the actors/ family table.
In order to simplify the drawing and trace the requirements dependencies I used a simple association between actor and requirement and an aggregation relationship between requirement family and requirement. Actors can link to any requirement.
The result looks like this :
This needs to be done in several phases: after some modeling, clusters of requirements can be identified and the drawing can be reorganized by reordering actors and requirements to improve readability.
The next step will be to map requirements to the solution processes, functions and components.…
Design Thinking is a process based on the collaboration between the users and a product designers to determine how to solve problems that the users have.
5 Steps to Build Perfect Web Sites Using the Design Thinking Process:
1. Empathy and Immersion
2. Define the Problems You want To Solve
3. Come Up with Ideas to Solve User Problems
4. Create Prototypes of Products to Solve the Users’ Problems
5. Test the Products with your Users
Source: read the integral article on the PHP Classes blog:
If you don’t want to install Archi, you can have a look at the model here:
I have received the authorization from my clients to publish it in order to:
- Encourage the modeling practice and reuse among public libraries
- Share with the Archimate community as an example
The model reuse is subject to the following restriction:
YOU SHALL NOT MARKET, SELL OR RESELL THE DIGB-SA ARCHIMATE MODEL
This model is published for reuse by public libraries. It can’t be marketed, sold or resold.
This model has been developed by Jean-François Declercq in the context of the DIGITAL LIBRARY SYSTEM ARCHITECTURE study by ordered by:
– Bibnet vzw
– Vereniging van de Vlaamse Provincies
– Vlaamse Gemeenschapscommissie van het Brussels Hoofdstedelijk Gewest
PS: A Dutch version of this model is available at Bibnet (http://www.bibnet.be).…
26 march 2014
The reports of the study on the current and future system architecture of the digital library have been recently published.
The term “digital library” is here used as a collective name for all of a library’s products, processes and services that are digital and/or automated.
The study summary lists the future work zones for the Flemish Public libraries:
- Business intelligence (BI)
- IT maturity
- Web presentation
- Identity and Access Management (IAM)
- Digital Collections
- Collection Management and cataloguing
- Architecture consolidation (SOA)
The summary is available in French, Dutch and English:
- Summary: DIGB-SA_ManagementSummary-EN
- Résumé de l’étude: DIGB-SA_ManagementSummary-FR-Final
- Samenvatting : DIGB-SA_ManagementSummary-NL
The complete study has three main chapters :
- Current system architecture of Flemish public libraries (AS-IS)
- Evolution of the Flemish public libraries’ System architecture (change requirements)
- The Future system architecture of Flemish public libraries (TO-BE)
The future system architecture is in fact a generic future-proof ICT blueprint for a public library. The blueprint is a set of business services, business processes, Applications, SOA Services and technological elements documented in the Archimate notation.
The complete study is available
- in English : 2013-11-27-DigitalLibrarySystemArchitecture
- in het Nederlands: 2014-02-04-DigitaleBibliotheekSysteemArchitectuurStudie
I would like to thank the colleagues who worked with me on this study:
- François Vermaut (IT Strategy, BPM, SOA, ITIL…)
- Rosemie Callewaert (Public Library field expertise, User Experience, BIBFRAME, FRBR…)
- Simon Kroeger (Proof reading english text)
- Veerle Vanlooy (Vertalingen Vanlooy)
I also would like to thank the steering commitee (Bart Beuten, Jan Braekman, Patrick Vanhoucke ,Stefaan Froyman), all the workshop and participants. Their input has been key. I would like also to thank Alexandre Lemaire who helped me to compare the Flemish situation with the situation of the Fédération Wallonie-Bruxelles.…
When trying to determine the best TO-BE architecture, it can be useful to describe future scenarios. Each scenario can be described by the 5W2H method : Why ? What ? Where ? When ? Who ? How ? How much ? (QQOCCP in french).
You can then discuss the pro/cons as well as the obstacles and pre-requisites of each scenario. Once you know the preferred scenarios, it’s easier to draw the target (TO-BE) architecture.…