Are you an I or a Pi?


This is a very interesting analogy presented in the Architecture Thinking course by IBM.

“Are you an I or a Pi?”

This is related to making a difference between specialists and architects. The question is actually “Are you a specialist or an architect?”

The picture above describes it perfectly. “I” is one specialty. If you are a specialist in Java/.Net/iOS/Android/etc. that is your “I”.

“Pi” describes architects. Architects might have one or more specialties (in the Pi picture there are two “I” specialties) but that’s not the architectural strength. Their strength is that line above those “I”‘s. They need to have a broad scope to be able to see the big picture and to guide specialists in doing their work.

Quite often people ask “are architects better than specialists?” or “is the architecture the next step in a growth of a developer?”

On both questions I would answer no. As an architect you need to have an IT background but you are not better than a specialist. Your scope is just different. Projects need both architects and specialists.

Take a look at it in medical terms. Architects would be General Practitioners while specialists (developers or SME’s) would be Surgeons.
A General Practitioner knows a lot and is your first go-to person in case of a problem. But GP can’t save your life. He can see where the problem is and then he can engage a proper specialist. A specialist can save your life but he will just fix the problem that GP pointed out. GP sees the big picture and can engage one or more surgeons to help you out.
But that doesn’t mean GP’s are better than Surgeons. We need both of them.

So, in deciding about your future role don’t think who is better or more paid, think about where your comfort zone is and what do you want to do. Being a surgeon to the rest of your professional career is fine. Being a GP to the rest of your professional career is fine as well.




Demystifying Enterprise Architecture


I have been in the IT world for more than 15 years now, where the last 10 years I spent in different architecture positions – ranging from solution to enterprise architecture. In all that time, many buzzwords were coming and going, hype cycles were rising like tsunamis and then gone like nothing ever happened. Exciting new technologies, tools and methods were showing up, people would master them or dismiss them and the world would go on. Hardly anyone turned their head back and asked what happened to that thing.

But during all that time, one question remained in the same time both unanswered and answered in so many ways that the correct one was almost impossible to spot. That question can almost become a benchmark for what ambiguity really means.

Let’s start with that question: “What is Enterprise Architecture?

According to Gartner Group: “Enterprise architecture (EA) is the process of translating business vision and strategy into effective enterprise change by creating, communicating, and improving the key principles and models that describe the enterprise’s future state and enable its evolution.”

But in reality…


But let’s start from the beginning…

Architecture is what everyone is taking about. When a new project is starting – “We need to get an architect to design it”. When an organization is going through a transformation – “Architects need to drive it”. When something goes wrong – “It’s architecture that we need to blame”.

When we talk about architecture, there are two levels that we need to differentiate:

  1. Solution Architecture
  2. Enterprise Architecture

Solution Architecture is almost self-explanatory. Your client confronts you with a problem and you need to find a solution to that problem.

Solution Architecture is not just about IT architecture. Solution architecture can apply to different domains. If you are designing a new business process then we are talking about Business Solution Architecture. If you are looking at the infrastructure setup of a new data center, then that is Technology Solution Architecture. Design of a new web application would be Application Solution Architecture. Defining new big data concepts like data lakes is Data Solution Architecture. And probably the last one would be Security Solution Architecture when you are designing an identity management solution for example.

Often these architectures do not live in isolation and if you are truly lucky, you might be joining a project where you need to cover all these domains under one Project Solution Architecture.

OK, that was easy part.

Now back to our mysterious topic – Enterprise Architecture.

In practice, all you need to do as an enterprise architect is to define these three things:

  1. As-Is state
  2. To-Be state
  3. Transitional states

And that’s it!


As-Is state describes your current enterprise. What business services your company offers, what business capabilities it has and what are the processes behind those. As-Is is also capturing all the applications your company runs as well as the entire infrastructure that those applications are running on top of. Ideally, As-Is state should have all of those artifacts linked together so that you can navigate this linked tree of information from top down (from business capabilities down to physical servers) or bottom up.

If As-Is state is correctly captured, you have a powerful tool in your hands. You know what assets your organization owns, what’s their TCO and what capabilities they deliver. You can do impact analysis and what-if analysis which are great decision making techniques for any CIO out there.

Yeah, and the As-Is state is only fully and correctly captured here:


In reality, most (read all) organizations have no clue what they own. Bigger organizations usually went through several merging and acquisitions where they inherited all the legacy stuff from different companies. Many organizations are federated in its nature, meaning that business units have certain autonomy that they use to buy/build stuff they need. Quite often two business units are buying/building the same stuff, not knowing that other units already have something they can reuse.

So, the reality of As-Is state is more like this:

In reality, you are drowning in the sea of applications, databases, business processes and technology components that you just can’t get grip of. As soon as you collect some information about your underlying assets, they change. You have to go back and ask what has changed so that you can update your As-Is state and so on… in circle… forever…

What most companies do in that case – they just give up! They say, “we can’t update our repository with all the stuff we have out there so we won’t spend any more time on that exercise”.

Fine… but… actually it’s not fine…

I am sure we all know how many TV’s we have in our houses. If we have enough of them, like one per each room, we won’t buy another one right?

Well, why should it be any different to a large organization then? After all, there is your saving potential – just stop buying what you already have!

I guess the true answer lays in the fact that some organizations just have lots of cash and they can afford that kind of behavior.


So, here’s the million-dollar question: “How do you know where you want to be if you don’t know where you are now?”

For those of you who already have millions of dollars, skip the question.

The answer is – you can’t know! You might have an idea where you want to be, but actually to get there would be difficult if you don’t know your starting position. Because the road can be anything between these two:


That brings as to To-Be state. Where do I want my organization to be in 5 years from now?

Again, the simple answer is – you can’t know! Things in this world are just changing too fast!

Changes are fast in IT as well as they are in business. Few years ago we didn’t have smart devices, and now they are the main sales channels. Both IT and business had no idea about it few years ago. So, any of your To-Be states defined few years ago are obsolete by now.

The future will become even faster. You are going to get hit in your face sooner than expected, as we are just at the beginning of the technological revolution. Take a look at the speed of adoption of some things:


With these increases in adoption, it’s very hard to predict To-Be state in 5 years in any domain – business, application, data, technology or security.

So, what do we do now? We gave up on mastering our As-Is state; we don’t know our To-Be state, so how are we going to understand our Transition states? By transition state I mean getting from we-don’t-know-where-we-are to we-don’t-know-where-we-want-to-be.

Should be easy… (good luck with that)


But bear with me; later on I might have few recommendations how to do it…

Let’s continue our journey into unknown by adding one more thing in the whole mix. And that is company politics!

Company politics is when the big guys are doing something to the small guys. The picture explains…


The company politics is that beast that everybody hates, but nobody can do anything about it. Politics is what comes up when you have different cost centers, independent budgets, separate business units and people with big egos. They all have their own agendas and stakeholders to satisfy, so having sympathy for the group level initiatives is very low on their priority list.

I often say that 70% of Enterprise Architect’s time goes on family counseling. Talking to everybody, trying to understand their problems, trying to persuade them that it’s all going to be OK, making them believe that you can be their trusted adviser and so on.


There are several methods that can help you in this family counseling practice.

The most prominent ones are:

  1. The Open Group TOGAF standard
  2. Zachmann Framework

There are plenty of other frameworks of course.

But all of these frameworks will give you a theoretical idea of what Enterprise Architecture is. They will also teach you a common vocabulary that is used in communication between business and IT. They will tell you that you need to be structured and that all of your artifacts should be organized in an architecture repository. They will teach you how to govern architecture creation and how to review architectures.

But they won’t go beyond descriptive concepts and narratives around them. The practicality and applicability of these frameworks is up to you do define… and that is a problem.

Every organization is different, so basically you need to tailor these methods to fit your organization.

Then the question of tooling comes up. What tools are out there to help  enterprise architects do their job?

Well, mostly MS Office tools. Most of architects use Visio, PowerPoint and Word to document their landscapes, present solution architectures and write architectural specifications.

More sophisticated architects would go for Sparx Enterprise Architect tool that is a great tool for doing solution architecture, but not enterprise architecture in my view. Sparx EA has plugins for all possible frameworks out there (TOGAF, Zachmann, ArchiMate, UPDM, DoDAF, MODAF), it can do business process and capability modelling, heatmaps, roadmaps and some other nice things.

Again in my view, the only true enterprise architecture tool is the one that implements Enterprise Architecture Repository. The following picture shows TOGAF representation of Enterprise Architecture Repository:


Enterprise Architecture Repository is where all of your enterprise assets are stored:

  1. architecture relevant documents
  2. reference architectures
  3. governance processes
  4. architecture review products
  5. As-Is, To-Be and Transitional states
  6. architecture and solution building blocks

It is a place where your artifacts are interlinked together and can show you the world of your enterprise from different viewpoints.

Unfortunately I haven’t seen any tool out there that does that properly. Enterprise Architecture exists more than 30 years as a discipline and still there are no proper tools out there that implement Architecture Repository per the picture shown above.

There are few big players out there:

I have tried them and I think that all of them have missed the point of Enterprise Architecture Repository.

First, every enterprise is different. The underlying meta-model must be flexible enough to support customization. But customization without vendor’s intervention. As a client, I need to be able to add/remove/change entities and attributes of the meta-model and I probably need to do that often. None of those tools can support it.

Second, it must be dead simple to use them! User interface of Alfabet for example is just overwhelming. Millions of options, reports, wizards, who knows what else. Architecture Repository is a tool to be used by business, compliance, architects, business analysts, basically anyone in your organization. It is not just for architects. So it needs to be super simple to use.

And last but not the least, pricing! It’s difficult enough to sell Enterprise Architecture practice to the business. Some of these tools have crazy licenses, which makes things even harder for us…



By now you either have clearer or even muddier picture of what Enterprise Architecture is. Both results are fine.

Now it’s time to give you some of the advises and recommendations that worked for me…



  • Get top level management support

Seriously, if you don’t have a full support from your CIO don’t even try doing Enterprise Architecture. Your CIO needs to believe in it so that he/she can defend it. EA practice will get into every corner of your enterprise and not many people will like it. You need to have a strong support if you wanna step on someone’s foot.

  • Start building Architecture Repository

Common document storage for your architectural artifacts is a good starting point. That will increase visibility, transparency and possibility for sharing and reusing. For this you can go with some cloud solution – Google Docs or Office 365.

  • Lightweight governance

Introduce Architecture Reviews throughout your software development cycle. That will help you validating that the original architecture is actually being implemented.

Start building Reference Architectures for your industry so that you can promote standards and also can have something to govern against.

Governance is all about carrot and stick. You need to give something for people to use so that you have a reason to beat them up if they don’t use it.



  • Focus on Core IT

What is common in these pictures?

Yamaha_MidnightStar_acpz Tesla-Motors-Inc.s-Model-S-Poised-to-Be-the-Most-American-Made-Car-2016-GLE-CLASS-SUV-HOMEPAGE-D

They all use the same roads!

As long as your infrastructure is setup up right, it doesn’t matter what kind of applications you want to run on top of it.

It also works the other way around – you can buy the latest and greatest applications out there, but if you have no means to run them then you just got a Porsche stuck in a mud.


As it is hard to see To-Be state and what business disruptions are around the corner, try to focus on the core IT services that aren’t going to change that frequently. Services that any new application would need, such as: integration (ESB) solutions, document management, workflow solutions, identity management, core financial systems, printing solutions etc.

  • Keep it simple and structured

Whatever you do, try to do it as simple as possible. It is very easy to create complexity, but it’s damn hard to make things simple.

Try to structure your world. Create a proper repository where you can structure information based on which you are making decisions.

  • Have great reports

A right report in a right time is invaluable! Look at your assets and artifacts and try to create as many views as possible out of them.

  • Look at what others are doing

There are independent resources out there that can help you in this journey. I can recommend CEB (Corporate Executive Board) that can give you insight into what other companies are doing in the Enterprise Architecture space.


That’s all… hope it was useful…






Lipstick on a pig?


The latest hype seems to be Software Robotics or Automation Tools.

These are business workflow tools that are doing repetitive tasks instead of humans. Basically they are programmed to “look” at one application and retype certain values to another application. That “looking” process can be either via Win API functions or just screen scraping techniques.

In any case, they are front-end integration tools that are “integrating” your legacy applications that are not communicating between each other. What a human used to do by re-keying information across many applications is now being replaced by these software robots.

The biggest players in this field are:

I truly admire these companies as they managed to find a niche area that is very attractive to large organizations. They understand how large organizations are inertial, especially when it comes to dealing with legacy IT systems (as an example, I have seen some of the core IT systems that are 43 years old!).

Also, these companies have a unique value proposition that appeals to all big companies: “we can help you get rid of people and save you money”.

Nothing wrong with that approach. It’s just direction where the world is heading.

The problem I have with these automation tools is that they are just prolonging life of systems that should be either upgraded or decommissioned.

Another example is Capriza tool that is seamlessly exposing your legacy application as mobile apps. Again, by doing screen scraping.

These tools are tactical solutions that are just hiding your problem under the carpet. 20140620-corruption

As an architect it hurts me to see these developments. We should ask more fundamental questions: “why these two systems cannot integrate with each other on the backend?”

Unfortunately, market is getting very competitive and organizations are under a huge pressure to deliver and to react fast on any change out there.

I believe there is no help for large organizations as long as this kind of mentality is dominant. Some new startups that are entering markets without any legacy behind are just going to swallow “big and old” players.

The sooner we start tackling real problems, the sooner we can start competing with the newcomers. Otherwise, so long…

Mastering IT Architecture


Today I got my Master IT Architect certificate by the Open Group.

The program requires applicants to demonstrate skills and experience against a set of conformance requirements through written applications and peer interviews. There are no training courses to attend, and no written exams to complete.

The Open CA program is:

  • The most trusted independent benchmark for validating an IT, Business and Enterprise Architect’s skills and experience
  • A distinctive, peer-reviewed, vendor-neutral, globally recognized, portable credential
  • Used by the world’s leading enterprises as an objective measure of capabilities
  • A proven guide for filling critical roles and responsibilities
  • An outstanding career move

There are 3 levels of certification in Open CA. They are:

  • Level 1: Certified
  • Level 2: Master
  • Level 3: Distinguished

If you have worked as an architect for some time (think 3 years is minimum) than you can give it a shot. There is a template that needs to be filled out. You need to answer on many questions and write 3 experience profiles. All that must not exceed 50 pages. And believe me that is a very challenging task. Trying to fit several years of your career and all the projects you worked on during that time on just 50 pages is very tough.

Also, don’t underestimate the effort needed to write it. It took me over 2 months to finalize the whole package. Members of the certification board are saying that it takes 1 page per day. So, 50 pages is 50 days, that’s approx. 2 months.

Once you have submitted your package, and paid 1.250 Eur, you then enter the review process that takes about 2 months as well. If they accept your submission you will then be appointed to a certification board that is consisted of 3 distinguished architects.

The interview is about 3 hours long, an hour per each board member. They are really nice people and they are not trying to trap you or make your life hard. They just want to make sure that the stuff you wrote is actually done by you.

So, my advice – go for it! It’s well worth all the time and money spent. After all, it’s the crown of your career up to now. Also, you will have 50 pages summary of you have done in the past 8 years. Things get forgotten easily, this is a nice way to keep them documented.