If you have some experience in modeling real-life, full-size architectures for large-scale organizations – preferably in the ArchiMate language, of course – you have likely come across the challenge of organizing your models in logical and manageable ways. In the following pages, we’re going to share our top 6 ways to organize your architecture models. These methods should help you keep your models neat and tidy, while also supporting better outcomes for your strategic initiatives. Let’s see what they are..
1. ORGANIZE YOUR MODEL REPOSITORY BY BUSINESS DOMAINS, INFORMATION DOMAINS AND TECHNOLOGY STACKSIn large organizations, you will need some substructure for your integrated current-state model. You can organize your capabilities, business functions and business processes by business domains or high-level business capabilities. That is a natural subdivision of the business world, both easily recognized by the people involved and the typical responsibility and authorization structures in your enterprise. The application and data part of your model repository you can organize according to information domains, consisting of:
For the technology part of the architecture, a business-oriented structure often makes less sense, as much of the technical infrastructure of an enterprise cuts across business or information domains. Instead, organizing by technology stacks makes more sense in many cases. These stack models can then be managed by separate teams with the requisite technology expertise. Setting up a navigation page to help people find their way around this structure is also very useful. Figure 1 at the top shows an example of this.
Two other model categories are 1) external reference models and 2) standards. For instance, the BIAN standard for the banking industry or the ISO/IEC 27001 security standard shown in the figure below describe your way of working, including your:
2. SEPARATE CURRENT- AND FUTURE-STATE MODELSIt is important to make a clear separation between what you have described about the world as you know it is today and the future that you envisage. Facts about the present and ideas about the future should be clearly distinguishable in your architecture models.One way to do this is to create a read-only, integrated reference model of the current state (possibly per domain, as described above) and separate project-level models that describe aspects of the future as it is being designed. The visibility of these future-state models is limited to the specific project team working on them, so people do not get confused by the work being done on future-state designs. Within these future-state models, elements of the current state that carry over into the future can be reused. Once the time has come to put the project results into production, the future-state models will become reality and will transfer into the integrated current-state model.
It’s important to note that the process for creating these models is very different. When describing the current state, it is often easiest to start with what is called ‘structure’ in the ArchiMate modeling language: the organization, applications, software platforms and devices that are readily visible in your enterprise. From there, you can look at their behavior: the processes, services and functions provided by these structure elements. As a next step, you might then look for commonalities and opportunities for synergy or rationalization, just as an example.
When designing a future-state architecture, however, you will often work the other way around: first you define the services you require to solve your business problem, then you outline the processes and functions that need to provide these services. Only once that is complete do you decide on the structure elements that will perform this behavior and deliver these services. This avoids the common trap of constraining your possible design solutions by the structures you know (e.g. components, systems, products etc.), especially early on in the design process.
3. SEPARATE MODEL CONTENT FROM VIEWS OF THAT CONTENTIn architecture modeling, it is important to distinguish the content of your architecture from views of this content that address specific stakeholder concerns, by visualizing part of the content in a suitable manner. The same model elements may appear in different views; vice versa, all views share the same underlying content.Typically, you organize the model content according to the types of elements you have modeled, for instance using the layers of the ArchiMate language (motivation, strategy, business, application, technology, implementation & migration), or even more fine-grained by defining separate collections of business processes, application components et cetera. The views on that content are best organized according to the types of stakeholders you address, with views for groups like business managers, process designers, application owners, data stewards, project managers, system administrators, and so on.
4. DEFINE NAMING AND OTHER MODELING CONVENTIONSTo be able to find anything in a large-scale model, you must know what to look for. In plain language, you will need to know what things are called – and how they’re labeled – in your model. This is why defining clear naming conventions is essential. Different organizations will have their own specific naming schemes, so no universal convention applies to all situations. Nevertheless, here are common tips that may help you create your naming process:
5. SET UP AN ‘EDITORIAL BOARD’To create collaboration in large, federated organizations, you cannot rely on simple top-down control from a central department. There must 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 benefit from each other’s experiences so you can build up your own library of organization-specific best practices.Working with such large and complex organizations, I have seen that it is often helpful to create a kind of ‘editorial board,’ composed of representative architecture and modeling experts from different areas of the organization. They can find shared ways of working and other commonalities across your architectures (such as the modeling conventions and structuring mentioned previously), and they can coach their less experienced colleagues in applying these practices to promote high-quality models.
However, an ‘editorial board’ is different from your typical architecture board, which decides on the architectural content itself. Rather, this editorial board supervises the way architectures are modeled and described. These are two distinct competencies: A good architecture may be badly documented, and poor architecture may be well-documented. Make sure both are well-done.
6. DEFINE CLEAR RESPONSIBILITIES, ACCESS RIGHTS, USER GROUPS AND PROCEDURESIn any large-scale organization, you need to be clear about who does what and who has access to which materials. If everyone can edit anything in your architecture models, you can guess what will happen. Things may get moved or entire models may be deleted. In general, I would not advocate hiding parts of the architecture from view (unless for specific security-related reasons). Architects should be trusted to see the work of their peers and make good use of that. However, you will likely need to limit write access to the people 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-state architectures in projects, each with their own specific models, as described above. Project teams have the right to change their project models, but their results are only published to the wider architecture repository when they are sufficiently ready, as decided by a lead architect or decision maker within the organization.
Culled from https://modernanalyst.com/Resources/Articles/tabid/115/ID/5246/6-Ways-to-Organize-Your-Architecture-Models.aspx
ClWith the increasing growth in knowledge and information about the aspects of Business Analysis and technical analytics domains, there is a notable increase in confusion when it comes to the real difference between Business Analysis and Technical Business Analysis. In fact, the two are often used interchangeably. However, the differences between the two practices are prominent. In this article, we will discuss each practice and the set of skills required to claim being a business analyst or a technical business analyst.
WHAT IS BUSINESS ANALYSIS?
Business Analysis can best be understood as the practice that enables change in a given organizational context by outlining the existing needs and recommending solutions to the said needs so as to deliver value to the stakeholders. In its simplest form, Business Analysis is a discipline that helps organizations resolve their existing obstacles by first pinpointing the existing problems, analyzing them, and solving them.
Simply put, Business Analysis entails identifying a given organization’s needs/obstacles and providing solutions to the said problems.
In many organizations, the only way to deal with a given problem is by changing the existing techniques/method/processes that are not working. This is precisely what Business Analysis entails – identifying and fixing business problems. It can also be referred to as the discipline of enabling change. It only makes sense that whenever a given organization’s problem is solved, the organization will benefit (either in terms of input or profits). In so doing, Business Analysis will have created and added benefit to the people associated with the given organization. In the end, Business Analysis always finds a way of delivering value to the stakeholders.
TECHNICAL BUSINESS ANALYSIS
Technical Business Analysis is quite a complex role. Some companies end up mistakenly looking for Business Analysis when their current issue could best be solved by Technical Business Analysis.
So, what is technical business analysis?
Technical business analysis is a second tier of business analysis dealing with the sole purpose of interpreting business requirements into systems and technology language that can then be easily understood by a technical audience. In so doing, Technical Business Analysis comes in as an entity of bridging between business problems and its technological solutions. The role of technical business analyst can only be appreciated after business analysts has executed its duties of identifying business problems. It is from there that the technical business analyst would take the business requirements developed by the business analyst and develop them into technical artifacts.
In the end, a business analyst would identify existing business problems of a given company which may emancipate from a business process or even system, then a technical business analyst would use technology to provide technical solutions to those problems. As such, Technical Business Analysis involves itself with the aspect of analyzing, transforming, and finally resolving the existing business problems by using technology. However, while it may appear that Technical Business Analysis is closer to technology than the business itself, technical business analysts do involve themselves intimately with business processes and functions.
KEY DIFFERENCES BETWEEN BUSINESS ANALYSIS AND TECHNICAL BUSINESS ANALYSIS
Technical Business Analysis;
SKILLS NEEDED IN EXECUTING BUSINESS ANALYSIS
One must always keep in mind that Business Analysis tend to be a multi-faceted discipline that requires that an individual to have a number of different skills to excel in it. It is such skills that will enable one to be able to figure out the current requirements of a business and proceed to comprehensively document them so as to figure out the solutions needed. Such skills include.
As explained above, the very fact that Business Analysis takes a universal approach in its applications as well as by it working on a set of predefined practices, it is used by companies that want to tackle their current problems and obstacles. The main premise of Business Analysis is the fact that it helps solve business problems creating value to the organization’s stakeholders. This means that Business Analysis entails figuring out opportunities that can be used to solve business obstacles and improve the existing business processes.Technical Business Analysis, on the other hand, is mostly used when the business requirements developed by a business analyst need technical solutions. Technical Business Analysis creates the very foundation through which business requirements can be solved by using technological solutions. This is the case as technical business analysts always take business requirements identified by the business analyst and proceed to use technology to find technical solutions for them.
Culled from https://modernanalyst.com/Resources/Articles/tabid/115/ID/5234/Business-Analysis-vs-Technical-Business-Analysis.aspx