Enterprise Architecture Introduction #4

Before I start describing the planned topic (a little postponed), something that has recently appeared on the forum for architects should be explained.

I heard the opinion that the role of Enterprise Architect is a role based on drawing diagrams and pictures. It is quite a strange and somewhat infantile statement.

In fact, the diagrams show graphically the relationship between elements so that someone who is not related to mentioned information system (IS), has an rough idea of scale and complexity.

The diagrams do not eliminate the text and documentation, but significantly accelerate the ability to quickly understand what elements are part of the system and how they influence each other.

It is much easier to show small parts and improvements on the technical level, because they are easier to visualize, because many people have knowledge of building the architecture of a technical solution from scratch.

Let me give you an example:

(...) the company obtained a 30% faster response to/from database queries (...)

If it were broken down into individual components, they could take the following forms:

a) faster disk - data access and data searching, significantly larger scale of I / O operations

b) reorganization of swap memory from disk to a separate area in the operating memory

c) changing the file system for database files and index files, changing the encryption method from RAID5 to a regular mirror disk

d) use of fiber optic connections to a disk array system based on ultra-fast SSD disks

e) reorganization of the query in such a way as to minimize the use of searching the entire database and intensive use of indexing

f) change of database architecture and use of other technology, more adequate to the query characteristics

g) faster processor or multiprocessor scalable configuration

h) use of database scaling at high load during peak hours

But all these elements have one thing in common: they are defined, they are measurable and can be benchmarked. And benchmarking is a good starting point to consider to extend it to other levels of the information system (IS).

We are still at the technical level discussion about IT solutions. However, the efficiency and effectiveness of IT solutions are not only at the technical level. It covers everything that directly or indirectly affects it.

There is a huge pressure on the market to try to adopt technical solutions (with all limitations) to apply this to the style of organisation of the company. This is an absolutely wrong approach and you can see that it results in endless integration of IT systems in the organization. In a very simplified way, it can be said that exactly what was required, exactly it was achieved. If the company's goal is to implement a technical solution, and not to solve a business problem from deep analysis, through an appropriate technical tool , it is resulting exactly what companies get. Consulting services more and more often take the form of purely sales services, in order to achieve a client-contractor close relationship, what at the next steps creates modularity of IT system or creates dependency of part of the company's IT system.

Many companies have such dependencies and gather around, for example, 30 sub-suppliers, each of them uses a different project implementation methodology and a different system description. Attempts to integrate such solutions are very difficult and there usually is internal opposition to apply any standardization. If the company does not work out and obligatorily implements some kind of good practice, then obtaining results will be at least very difficult or impossible at all.

Why I wrote this using some type of simplification?

The company consists of people and their skills in mutual interaction to achieve specific business goals. There is a need to define common definitions, define goals, principles of interaction in the areas of responsibility and, above all, link activities with business processes. Let's not forget about continuous improvement in a more or less formal form.

You can argue about the presentation method, types of diagrams used or even colors, but this does not change the situation that without measurement methodologies (e.g. SMART or others), improvement methodologies (e.g. PDCA or others), description methodologies (e.g. TOGAR / Archimate) , process management methodologies (eg ISO 9002, 27000 or others), the company will always be at the stage of stagnation in which the only correct statement will be "there is nothing can be done here". A good starting point is an attempt to describe the corporate architecture - that is, gathering in one place a full repository about what the company uses, by whom, how and what dependencies are there.

When creating a kind of carbon copy from a technical solution to a process management solution, similar principles should be applied, i.e. to measure something, you need to define the method of measurement and realistically connect it with key elements, which are quite often referred to as milestones in project management. This is why I called at the beginning the database example.

If a given process is based on assumptions as for the project in the classic sense, i.e. there are limitations such as resources, budget and time, then such a process is a good choice for improvement - because the measurement of each element is known and required.

In the case of other processes, existing but not defined in the book of processes, it is necessary to develop a methodology on how to manage such a process or, less formally, how to solve business problems at the corporate and managerial level. Quite often, new market or customer requirements are not yet defined but it does not mean you will avoid this in the future.

I will give an example to understand the issue.

A few years ago, the "on-line" ordering process was carried out through a telephone service - by calling the call center - providing user’s data and, usually within 5 working days, the customer would receive the ordered goods. All processes were described and worked without any major problems. All processes were at the level – state-of-the-art.

Due to the time constraint (call center working time) and the maximum number of accepted orders, attempts were made to increase the number of accepted orders. In the classic approach, it was possible to increase the working time of a call center to 24 hours a day or use a different method of receiving orders. As you can easily guess, the methodology of ordering via an on-line website was widely accepted and the role of the call-center was reduced to the role of teasing customers and resolving possible complaints. All processes were described and worked without major problems. On the other hand, due to the operation of competition (other companies on the common market), although the processes worked without any objections, they had to be changed or expanded or a little tuned.

Such a driving factor were, for example, deliveries for the next day until 9:00. [Today it is a little weird because it is new normal to have next day delivery]

This forced changes in the working time (evening and night hours), changes resulting from transport (only night deliveries to the so-called intershipment hubs), integration of the IT system of the online store with the logistics operator, coordination of deliveries and unloading (waiting time), monitoring of stock and shortening the storage time on storage shelves. This is, of course, a great simplification, but that is why I am giving this example to show that corporate architecture perfectly fits for implementation for such examples.

Was it possible to find the cause of the falling number of orders without data analysis, especially when these were factors independent of the company in which the processes were analyzed? Would any of the process owners be able to draw conclusions beyond their scope of duties, e.g. dispatch manager, on the impact on the company's revenues from the point of view of the tax manager? Such knowledge cannot be obtained by operating only within the scope of own processes.

However, having a full map of processes related to their measurement, it is much easier to find relationships between individual elements in the company. Of course, this information can be specified and presented in the form of a 300-page case study document, but without the abbreviated version it is too time-consuming, and often such information may be out of date - the development process to gather all information may take up to several weeks.

And after this slightly long introduction, I would like to come back to the statement at the beginning. The role of Enterprise Architect is NOT only a drawing and drawing role. The architect presents his observations and knowledge in the form of a graphic abbreviation, based on the standardization of symbolism and the language of description in the form of written text.

Since I am closer to software development, I can say that there is not only one type of Corporate Architect. In my industry there are:

? data architects

? process architects

? information security architects

? architects of technical solutions (migration, networks, storage)

? software design architects

? risk architects

and many others that I have not mentioned because they are in narrow specialisation of designing the kind of new architecture.

Corporate Architecture is the integration of knowledge of many sector’s architects into information saved in electronic form in IT Systems. It is a process of continuous improvement based on changes, it is a modification process under the influence of external factors, it is a process of responding to previously unknown or on external factors which previously not influenced the company.

I do not want to quote some common Internet Texts, but one can agree with one, "the bulb was not created as a result of continuous improvement of the candle production process". It seems that the lack of corporate architecture could be one of the reasons why such a big civilization change was not noticed. But who cares about candle manufacturers today, since the bulb offers 20x more possibilities, not to mention the quality, brightness and duration of use. This example is accurate because it shows that a business model can be by market verified despite the fact that no one does/did anything wrong.

And here is a valuable comment from my interlocutor (Marcin W?sierski), who very accurately presented that even if we use SMART methodologies and achieve higher or lower results in relation to the assumptions for the processes, the measured parameters should be re-analyzed on the technical and organizational level for processes. The attention is accurate because the manager responsible for the process may unexpectedly be described as ineffective, because by accident his process may show the defectiveness of the method of measuring previous processes.

While it is fairly easy to find someone to blame for ineffectiveness, it does not change the fact that a wrong description of the process leads to wrong conclusions about the process. But there is never only one process in a company. There are dozens of processes that are defined, but there are also undefined ones that function in companies based on casual conversations, e.g. over morning coffee (recently less because everyone sits in the Home Office). But this shows a certain tendency very well. Along with the dispersion of people, the inertion (delay) in the exchange of information increases and information islands are created - that is, people will focus on knowledge on a given issue and it is difficult to obtain this knowledge through the natural barrier related to distance. This results in decentralization rather than the creation of central repositories. This is a big risk for companies because the re-analysis will also take a lot of time because there will also be an elements related to booking time for talking to employees - which is also a kind of paradox. This, in turn, will make the flows of information slower.

An interesting topic is the presentation of cloud solutions in corporate architecture. I asked a few people about this issue and the answer was not so clear - because it is a different approach related to services. In the cloud, we buy or use a specific solution - no matter how it is configured, until we combine it with our IT systems. As long as we perceive the cloud as something virtual and undefined - I am not surprised that many people have a dilemma how to present it in diagrams. If, on the other hand, we simplify that cloud is a server but now our but someone else - then there is a natural statement that if this is the case, it means that we have to extend our architecture and processes to services in an external company called the cloud. This applies to both the public cloud and the hybrid cloud.

So the answer is: use exactly the same description tools as for your own systems. I asked a question how to describe systems that automate activities related to scripting languages. Probably the best option is to present the core function of the script or connect to the scripts’ repository in read-only mode. Thank you for your suggestions (Maciej Rostański).

Coming back to the issue of data security. The description of the corporate architecture is a description of the company's key success factors and the identification of critical elements. Is it valuable to other businesses? I think so - because it is a valuable source for gaining a competitive advantage. On this basis, you should also analyze who the software vendor is. Going slightly against the current trends, but I have to touch on this topic, the current political and economic situation is dynamic. The phenomenon of ordering acquisition illegal data becomes a big problem for security and security departments in companies. In the case of error reporting and telemetry data, companies have no control over what is communicated in these reports and to whom. This is a risk and it is better to limit it to the level of local market suppliers that share the same jurisdiction as the user company. The same goes for the software vendor for Enterprise Architecture.

That's all I wanted to mention in this part. And the topics that are freely included in it are:

• corporate architecture and measuring processes
• standardization of methodologies and long-term measurable benefits
• continuous improvement can also have disadvantages
• and remember that information security is still very important.

The next parts may be created, only that it depends on the interaction with the posts. I am writing this for those who read not for myself.

===

In a series of several articles, I would like to focus on presenting the issue based on the Achimate/Togaf model and the MID Innovator software package. Articles will be published every 7-14 days and their aim is to popularize the issue and encourage its use in practice.

Links:

• MID Innovator: https://www.mid.de/en/download/innovator-downloads/enterprise-modeling-suite
• Archimate Tool: https://www.archimatetool.com/download/
• Togaf: https://www.opengroup.org/togaf

#EnterpriseArchitecture #AliensIT