In the previousinstallment of this architecture organizationseries, I wrote about organizing your model repository according to business, information and technology domains. I alsoexplained the need tocreateseparate current- and future-state models, and the separation between and model content and views. In thispart of the series,I have a few more things to add onthe topic ofnaming and modeling conventions,as well as advice on how to setup governance and quality assurance structure around your models.
4. Definenaming and other modeling conventions
To be able to find anything in a large-scale model, you have to know what to look for. In plain language, you’ll need to knowwhatthings are called-and how they’re labeled-in your model.This is why defining clear naming conventions is essential. Different organizations will havetheir ownspecific naming schemes, so no universal convention applies to all situations.
Nevertheless, here are common tips that may help you create your naming process:
Let business experts‘own’the names and definitionsof capabilities, business processes, functions and the like. If IT people invent new names for those, the businesswill often fail to recognize ‘their business’ in it, leading to misinterpretations and misunderstandings.
Define specific naming conventions for specific types of elements.For example, use a present-tense verb plus a noun for process names (e.g. ‘Handle Claim’). That way, the name of an element already gives you information on the type of thing being modeled.
In large organizations, use pre- or postfixes for names, such the business domain of the element. This is particularly important if these domains use the same names. For example, in an insurance company, different domains like‘health,’‘life’or‘property’may each have a ‘Handle Claim’ process, but these processes will differ. Calling them ‘Handle Claim – Health’or‘Handle Claim – Property’ helps distinguishbetweenthem.
Make a clear separation between different aspects of the same real-life entity being modeled.If you model a customer who takes part in a process as an actor, don’t use the same name for theinformationyou capture on that customer. Youshouldalsohave a different name from the customerfileordatabasein which you store that information. Calling all of these elements ‘Customer’ will surely confuse the hell out of anyone using yourmodel.
Be selective in your use of modeling concepts.Languages like ArchiMate are very rich and powerful, but you will seldom need alltheirconcepts.Choosing which concepts to use for which purpose and limiting yourself to the essentials is key to keepingyour architectures easy to understand.
Figure2. Overview of your EA capability, ways of working and best practices.
5. Establishan ‘editorial board’
To createcollaborationin large, federated organizations,you cannot rely on simple top-down control from a central department. There has to be room for local variance simply because,in large organizations,no standard will fit all situations.
Nevertheless, you do need to coordinate between different departments and domains to ensure their ways of working are compatible, and to share and benefitfrom each other’s experiences so you can build up your own library of organization-specific best practices.
Working with such large and complex organizations,Ihaveseenthat it is often helpful tocreate a kind of‘editorial board,’composed ofrepresentative architecture and modeling experts from different areas of the organization.Theycanlocatesharedways of workingand other commonalities across your architectures(such as themodelingconventions and structuring mentionedpreviously),andthey cancoach their less experienced colleagues in applying these practicestopromotehigh-quality models.
However, an ‘editorialboard’is not the same asyourtypical architecture board, which decides on the architectural content itself.Rather, this editorial board supervises the way architectures aremodeled anddescribed. These are two distinct competencies: A good architecture may be badly documented, andpoor architecture may be well-documented.Make sure both are well-done.
6. Define clearresponsibilities,access rights, user groups and procedures
In any large-scale organization, you have to be clear about who does what andwhohas access to which materials.If everyone can edit anything in your architecture models, you can guess whatwill happen. Things may get moved or entire models may be deleted.
In general,I wouldnot advocate hiding parts of the architecture from view (unless for specific security-related reasons). Architects should be trusted tosee the work of their peers and make good use of that.However, youwill likely need tolimit write access tothepeople who have a defined role in creating or updating models. Otherwise,your models will quickly become a mess.
One way to do this is to organize the work on your future-statearchitecturesin projects, each with their own specific models, as described above.Project teams have the right to change their project modelsbutthe results are only published to the wider architecture repository when they aresufficientlyready, as decided by a lead architector decision maker within the organization.
Figure3. Common architecture-related roles
Enterprise Studio’s Team Platform supportsyour organization’s differentprojects,rolesand rightsfor designers and lead designers, anditoffersuser groups that can be organized asproject teams.Moreover, theworkflow facilitiesin theHoriZZonportal allow you tocreateapproval and review workflows to organize thearchitecture developmentprocess.
Interested to learn more aboutthe way we support large-scale architecture endeavors?Join our webinar or book a demonstration
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: