Enterprise Architecture

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.

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“!

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.

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!

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.

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!

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!

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.

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.

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.

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?

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.

"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?

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 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.

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.

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.

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.