Enterprise Architect portal

Architect Archers

  • Cost equivalent of standard complexity unit

    I work on the next step of the complexity as architecture management problem: find the cost of complexity. The approach is based on the complexity measurement has many articles here in the portal and I try to find a way to define the cost of a single SCU (the Standard Complexity Unit). For the research of defining the cost equivalent of SCU, we have the following hypothesises. The cost equivalent of SCU will be referred as CCE – Complexity Cost Equivalent.
  • Source code analysis to build architecture repo

    Did you know that, if you are analyzing a program code, then you can visualize and create the relationship diagram of the program? You can show, which application is connected to the others, and the internal calling graph of the given software. To utilize this knowledge, you need to learn how to analyze a real program code properly.
  • Comparison of two enterprise architect management solutions

    The perpetual question for enterprise architects is, which is the best enterprise architecture management tool. I have my favourite based on the past years experience, which I selected after a careful analysis of potential candidates. One of my clients requested a comparison between two tools and I would share the results here. Shortly the two tools are SAMU from Atoll and EA from Sparx. The summary of the comparison is, that they have to exchange the name they have! SAMU (System Architecture Management Utility) is a real enterprise architecture management tool, with all necessary aspects, while EA (Enterprise Architect) is a great system design tool, with very limited capability to be extend to enterprise wide repository.
  • The strength of steel: Build Redis cluster on well-controlled Linux environment

    Referring back to article The structural strength of steel, I will share some practical examples to encourage architect colleagues to break out of the role of „boxes and lines“ - which is usually expected from us. All of us should know stones and bricks what our architecture is built from - still should not be the best bricklayer, but even not the worst! This first article is an infrastructural task, building a Redis cluster in well-controlled Linux environment on a RHEL7 host.
  • Being agile or doing Agile

    Today, all companies wants to become agile. This is great. Most of them wants to be agile by applying one of the Agile methodologies. What is strange. Let’s go through the intention, what shrives this „agility movement“!
  • Ammo Domini

    I saw and heard many times (certainly not at you), that professionality is over in the IT field. Quality falls, deadlines are missed, costs are increasing and the joy of creation lost somewhere on the road. In the past everything was better and so.  What could be the reason? Large projects are still exists, empowering targets are still there, more money spent then ever - it seems to be a perfect situation to fly and still... I collected you some reasons for those cases when this bad feeling is right. Some ammo for the feeling of 'anno Domini'.
  • Competition is the fuel of improvements

    Without competition, the things will not improve. On the other hand multiple parties in a competitive situation may cause different problems. Let's go through these issues and get some tips to handle them.
  • Deliver values or observe the rules?

    If you never met this question you are living somewhere else but not in the IT industry! Here I collected some practical examples you may refer to when facing the question in the title. Here at the start my position about rules and principles: freedom is made by great rules and this is a basement to maximise ability to change! This article is the continuation of Rules and exceptions article.
  • And the best methodology is...

    What is the best development methodology? Waterfall? Agile? An iterative model? Something else? Companies and projects are looking to find the best approach to deliver on time and on budget and still keeping the scope. People are arguing in personal discussions and forums highlighting pros and cons about their best one, but I did not see the ultimate answer. Now I can help you to have it!
  • Size does matter!

    The eternal question is if size matters or not? One says it is important others think it is not, while there are people saying: it depends. What is the best size? Sure you may say the larger is better? You are maybe right. May be not... Come and read more to get the answer!
  • Reactor tester UI

    We reached the next staged to make Reactor to be more simple to demonstrate. Till now, it was possible to try it out through Swagger-ui and a chatbot, but from now on you can play with a browser based responsive UI to learn about Reactor. This UI enables all operations about cart based service manipulation: open a cart, order or remove product offerings or drop/commit a cart as you wish.
  • The general mistake of architects

    New year, new ideas. Look into the details of a new dimension of architecture measurements, extending the minds of The immortal temporary solutions article. The new dimension is Success, based on the definition described in new book from Albert-László Barabási: Formula - the Universal Laws of Success.
  • Create a chatbot interacting with Reactor

    Reactor was made to serve each type of front-end applications, who want to handle multistep service manipulation carts. The interfaces have sophisticated data structure to minimise the API requests, like an add operation can respond with the new CurrentPortfolio state of Reactor transaction together with the update AvailableProductOfferings list. Other it is fine for many applications, others require simplified interfaces having predefined standard response structures. One example is chatbot.
  • BREAKING - Santa used Reactor!

    Waking up at the morning and checking how Reactor demo environment is, I recognised the setup of Santa Claus present and birch. Not only do Santa exists but he follows novelties!
  • OpenAPI implementation and a demo

    In the last article you read about our project experiences using OpenAPI. Here you can learn about the target we had and the product we implemented. On the top of the information, you gain a demo access to the solution too what we call Reactor.
  • OpenAPI exercises

    We may say that OpenAPI is the latest craze on the field microservices. Otherwise it is also true that this specification helps a lot to implement standardised APIs. We gave it a try to implement our new portfolio element interfaces on OpenAPI basis and this article is to share to you our hands-on experiences. The results of the development, where we collected the expereinces below, will come soon.
  • Threat or Risk?

    Differentiation between threats and risks are crucial part of architecture design. Designing and implementing a solution based on threat patterns instead of analysed risks, may lead to unstable and extreme expensive situations. What is the difference between threat and risk? Threat is a potential issues in the future what we afraid of. Risk is a threat, which we analysed probability and potential (negative) impact. This means threat is more an emotional thing, a kind of theoretical thing, while risk is more practical.
  • The structural strength of steel

    The last article about the discussion of two "black-belted" TOGAF architects about the nature of architecture management finished by the words of "A good building architect needs to know the structural strength of steel before they design in it," Let's see some practical examples of 'steel' together!
  • 15 years before - Understanding the IT architect's place in today's business environment

    I used to refer to the article below, which is unfortunately shrank in the information ocean of the internet. Luckily I saved that to myself to be ready all time, therefore now I can share it to you. Most of the text is saved from http://www-128.ibm.com/developerworks/ibm/library/ar-togaf1/. Please read the following discussion between David Jackson and Andras Szakal, certified ITAC architects and key members of TOGAF.
  • A tail of Rulefort and Cheaperville

    Why do you need Enterprise Architecture management? Based on the definition you find on the portal, you may know - or not. This article is for two kinds of people as the people has two different kinds: one understands why enterprise architecture and the other does not. Those who understands may find some good analogy to describe the necessity of EA, while the others would make sense of the essence. First of all, remember: EA is not a must!
  • The best team is...

    The best team is where all members can say: the team cannot be successful without me and I cannot be successful without them. This is an extra mind of me for the Do you need a team player? article.
  • Labyrinth of Target Architecture

    I was thinking and working a lot about target architectures. Usually it is expected that you as architect will define a kind of map, which can be interpreted anyone in the company and reach the shiny targets on low cost zero time and no business outages. I would not say that it is not possible, rather if you plan cost, timing and migration phases but it is far to be simple. The real issue is that a target architecture is a collection of demands driving to ideal situation, which is not necessarily the place you would be; and the price tag, the duration and the full freeze of "disturbing" changes to reach the ideal situation makes most of the target architectures unreal. Let's see why!
  • 1+1=?

    The best answer in IT for the question is 0 with a carry flag. Team building approaches have different answers they think it is more than 2 what is the math answer. Is there any cases when the result is less? Assuming that the result is the value for money or the ability to change ratio in the architecture then yes, there are many cases when the performance will be much worse if you have 1+1 instead of tan appropriate 1. The following stories are not real they did not happen neither mine nor your past!
  • Architecture decision making procedure

    The third part of the series about architecure management directive. It shows the teams you have to organise and the mechanisms to operate to reach ideal point of transparent and clear decisions and rationales. The roles you see can be found in TOGAF while the processes are following the main disciplines of democratic voting.
  • Architect roles and responsibilities

    The first part of preparing architecture directive discusses how to set up the architect's virtual organisation. This article gives you the details of functional and virtual roles played by architects, which will be the basis of the next chapter, the decision making mechanism. Beyond the Domain and Enterprise Architect roles that was introduced before, here you will meat a new, the Lead Architect.
  • Sun Tzu: The control of large force - in Architecture Management

    The control of a large force is the same principle as the control of a few men: it is merely a question of dividing up their numbers. Sun Tzu: The art of war What should it mean in the field of architecture management? What to divide and how? How to keep control about a large Enterprise Architecture? Finally the recipe is the same as for war forces: you need an organisation, a kind of "command hierarchy" which enables the appropriate control over the entire Enterprise Architecture. This is the first part of a series about preparing Architecture Management Directive, which was one of the topic selected by you in the What would you like to read more? questionnaire.
  • Rules and exceptions

    The exception proves the rule. I do not want to argue about this statement but I'd like to understand how exceptions behave and when they show that something is bad. This train of thought will be about principles and processes we are closed around. Certainly the principles mean architecture principles in this portal and the processes are mostly those ones, which you find around the architecture management: orders, development change requests, infrastructure changes and so.
  • Do you need a team player?

    The automatic answer for the question is: yes, certainly. The actual cultural flow as that each time you have to play the role of team members. At every day; in every projects and activities. Are there any issues with this approach? Unfortunately yes. Come to read them.
  • What would you like to read more?

    Based on some readers responses the ideas came up to ask you what could be the most interesting topic for you to read. The following poll does not mean that the other topics will not be processed later neither that others will not be published beforehead or in parallel. Certainly if you feel something is more interested for you beyond the polls just let us know by writing an email or opening a discussion in the forum!
  • Fix your Architecture or start "tabula rasa"

    Here are some thought about the important question frequently raised - and we are not brave enough in to go into details. Large organisation are facing with the issue of complex "hairball" architecture, which is not performing well. Frequently the changes, which entitled to fix the performance results more issues and even worse performance. Performance: this case it could mean all the business aspects, including reposnse times, TCO, time-to-market and so, finally the aspect of Ability to change.
  • The profile of a good architect

    How do you recognise the good architects? What are their characteristics? There are some certain things, which as all certainties are so dangerous because of the different interpretations. On simple certainty is: an architect is the "owner" of the architecture. Fine. "Owner" as a farmer, or "owner" as an investor? Both the farmer and the investor would have similar target, to increase the earning, while their approaches, actions, interpretations, viewpoints are so different. After discussing many interesting topics and tasks the architects are working about and sometimes defining their roles it is the best time to pull the "ideal" architect out of the shadow!
  • Building a live architecture knowledge base

    Each knowledge base about architecture faces the same challenge: find the balance between details and accuracy. The less details would mean simpler maintenance of data while it certainly less usable. If you have limited resources for future maintenance you have to make compromises. This article shows the way you can built up-to-date usable knowledge base with no bad compromises about scope and usability.
  • The immortal temporary solutions

    All we know applications, which are well design implemented on the right way but need continuous caring; and yes, we met those ones, the "temporary" solutions, which are surviving everything with no caring and no way to be killed. What could be the reason?
  • Early bird or second mouse?

    "Early bird gets the warm, the second mouse gets the cheese." (W Nelson) Which one would you be? The certain answer is: it depends...
  • Automation

    One of the most famous topics today is Automation in the IT era. There are many different interpretations - as usual - therefore it is so important to define some levels of automation and the most interesting fields to focus on. There are two main areas of automations: business function automation and systems operation automations. Another differentiation is if the process which is automated means the it is running with zero touch or the automation means that users of the process gets predefined steps, tasks to execute.
  • How to build simple architecture?

    All we dream about simple architecture. Everything you always wanted to know about Complexity article described an approach to measure how complex our architecture is. The next question is to find the simplest solution in a multi-variable situation, which usually called project. This article shows an approach which ensures that all functions you implement will be on the best place from overall complexity point of view for greenfield cases, while we will discuss about brownfield situations also.
  • Product portfolio complexity

    The most frequent criticism about product portfolios is: too complex! Based on the articles, which describes the problems of measuring complexity in general take a look to the product portfolios. A marketing manager defined me in the past: "Making a simple portfolio is an easy task; define a profitable one is the same. Creating one, which is simple and profitable is almost impossible." I do not know the medicine of the problem, but the method described here will help you to simplify using an exact measure same as financial calculations.
  • Everything you always wanted to know about Complexity

    "The law of entropy tells us that the battle for simplicity is never over." Roger Sessions. All we now similar laconism about the problem of complexity. On the other hand, each Enterprise Architect knows, that our focus is to have a simple architecture. The real challenge behind this mission is that we are trying to optimise something what we cannot measure. The missing measure is the persistent doubtfulness if we go to the right direction. What is the solution?
  • Price tag of project delays

    How to calculate the cost of project delays? This article describes an approach, which shows the cost of delays in the percentage of net present value  (NPV) of projects. The theory is not prepared to use on a single project. The target is to show the cost of delays generally for a given organisation, which runs several project in parallel, since the method uses generalities. The result is usable to help avoid or eliminate the bottlenecks in the company or organisation. The calculation prescinds from the every day’s business but still focuses to the real problem, which is the accurate delivery of project targets, by effective resource allocation.
  • The managers of the enterprise architecture

    The topic which enterprise architects are working on is architecture management. This is a standing locution. Do we really know the meaning of the two words? Let's look behind the scenes and define properly what we are speaking about! The article uses common definitions of architecture and management then interprets the management functionalities from architects point of view.
  • What should we learn from Semmelweis?

    Ignaz Semmelweis was the "saviour of mothers". He was early pioneer of antiseptic procedures. He was referred to a mental institution - the place he died later. The linked article shows the details of his invention and invoke some thoughs of us about our "hygienic" work about managing Enterprise Architecture. Let's see some aspects, examples from EA practice when we work on something strange to our environment.
  • Architecture maturity

    The Enterprise Architects as every professionals naturally would like to know how effective their work and how big their contributions in the business success. The maturity assessment of your Enterprise Architecture could answer these questions - and should be the basis of your improvements in the future and helps showing the provided values today.
  • What is Enterprise Architecture?

    There are many different types of architects: solution architect, domain architect, application architect, enterprise architect, lead architect and so on and so on. We would see the difference between them and through this separation we reach the definition on Enterprise Architecture and Enterprise Architects.
  • Machine learning or Evolution programming

    The topic of machine learning is one of the most popular topics today. The expectations about "Machines" are so high - frankly. My feeling is bit the same as decades before, when the "Computer" can answer everything, like the wizard of the clan. This is the best momentum, while we are still on the peak of the hype cycle, to collect all pros and cons about the topic to be well prepared.

About Architect Archers

Architect Archers are Enterprise Architect professionals and mentors.

Our mission is to build Your Archers team while defining, aiming and hit your Enterprise Targets.

Enterprise Architects

Our exceptional team of experienced Enterprise Architects with a great track record of successful implementations of large enterprise-wide projects is ready to your challenges.

Architect Archery

Like great archers we have the right tool (the Bow), the models and processes (the Arrow) and the experiences (the Training). All the things needed for Architects is ready in our Archery program.


As an architect, I often face the problem, that our profession, enterprise architecture management has not been canonized yet. It means that the results, processes, and approaches of architecture management are still more an art than a real profession, therefore the results are not repeatable and ready to validate by anyone else. Based on the great background of frameworks like TOGAF it is good to collect architect practitioners and share our knowledge with each other. This is the fuel of introducing Architect Archers portal.

Tamás Nacsák   

© 2017 Architect Archers