Category Archives: Software Architects

The Pied Piper of Architects

The tale of the Pied Piper refers to all of the towns’ rats being led away, followed by the children after he wasn’t paid. I see the same thing happening with capable IT architects – the analogy works even if you can’t decide if architects behave like rats or children. While corporate IT departments are busy with other things, the real architects are slowly disappearing.

Definitions of the architectural role aside, let’s for a moment assume that an IT architect is a technical person with significant experience making a technical contribution to a project. Look around within your own organization and count how many people who are actively working as architects that are above thirty five, in their forties and their fifties – I don’t count very many. It seems strange that with IT systems being so darn hard to build successfully every time, that there is a lack of receding hairlines on our technical teams. This is not necessarily the case in other industries – most surgeons are considered to get better with age, right up until they are too shaky to hold a scalpel. My grandfather finally stopped working when he was in his seventies, spending every day on civil engineering sites – he had built virtually every major building and offices in the city and was useful to have around.

Where the IT Architects are going

If as an architect you can coerce a multi-million dollar system into existence, chances are you have a pretty broad range of skills. IT architects, in addition to technical knowledge, can project manage, lead teams, handle politics, understand business and so on – all of this in a fast-paced, highly stressful environment. It is pretty easy to handle a career change.

Some architects have moved out of IT completely – I know some who have become pretty good property developers, while telling me how great it is because building technology is fairly static. Some stay in corporate environments, even consulting, doing things such as project management – it is far easier to brand yourself as a senior project manager than an architect. Some move onto the supply side of IT, using their experience to sell products, services and resources to corporate buyers.

Most do less and less architectural work on a daily basis, lose touch with the current technological hype and feel that it is not worth the effort to re-skill again (intentional).

Why the IT Architects are leaving

The reasons should really be handled by a more substantive survey, but there are some things that really annoy architects and make them throw up their hands and think “I’m going to become a project manager!” Here are some of my theories.

Fifteen years of experience overridden by technical developments in the last year

There is a perception in IT that the more you know about the latest technology, the better you are. While this may be relevant for part of the project team, much of the work that needs to be done is not latest-framework specific. Imagine an architect with fifteen years of experience focusing briefly on non-technical aspects such as quality for three years – by the time he tries to become involved on the latest project he is considered out of the loop and drops a couple of rungs in terms of technical seniority. Architecture is a lot about abstractions and as much as developers will say how radically different v3 of the framework is, the abstractions still remain the same. At some point good architects say “This is the last framework/language/methodology/platform that I am going to learn if we buy into the ‘next big thing’ I’m out of here!”

Seen this movie before

Do you ever get the feeling that in IT we are continuously re-solving problems that were solved a long time ago? I’m not even talking about that latest language, framework or other technologies that could arguably be evolving. I’m talking about things like handling temporal data, long running transactions, concurrency and contention and so on. Often architects find themselves mentoring, arguing or persuading others that if they choose a particular approach they will run into well known problems that may have been solved thirty years ago. Obviously this is the architects role – imparting their knowledge and experience, but sometimes they are flat-out ignored by people who think they know better because the technology has changed. In these cases I often start my counter with “I’ve seen this movie before and it has an ending like Titanic” – by now, people on my team know that it is a prompt to pay attention to avoid pain.

He doesn’t code

Amongst architects the discussion as to whether or not an architect codes is unnecessary. The problem is that the technical members on a project feel that the architect should be coding and their reasoning is sometimes valid. A good architect is stuck in the middle – too technical to be valued for business knowledge and not a good enough coder to earn street cred from developers. Even coding architects find it difficult to keep up because they are not coding all day every day.

Salesperson Competition

Pre-sales techies are the bane of virtually every architect – energetic semi-technical salespeople that have all the latest brochures, white-papers, presentations and anything else to get business excited. Sometimes by the time the architect becomes involved, business is so sold on the particular product that the train simply cannot be stopped. Instead of inviting architects soon enough, and face it they don’t get as excited and can ruin a ‘fun’ demo, business holds back on architectural input until they say “We have bought this product and it is a strategic fit – please get it integrated with all the other products that we have bought”

False Credentials

I was involved in a project with an awesome architecture assembled and delivered by a brilliant architect. When the final testing was going on external auditors rocked up to do an assessment – fair enough, it was a bank after all. They conducted a few days’ worth of interviews and inspections and in their auditors report proudly announced that the architecture was bad (it should have been in a cube and not a relational database). How on earth would an auditor know, where are his qualifications, what is the basis for his argument, can we see the report, when can we have a meeting? Nothing… no answers… nada! “The auditors have spoken and it is so recorded, entered and agreed.” Architects, without recognised qualifications and the rest of business not really understanding what they do are always at the whim of roles that traditionally have more clout and credibility.

Make him a manager

Sometimes, the best way to keep experienced architects around is to give them an office and a larger credenza. That way they can justify the cost and still have someone who knows how all their systems hang together. The problem is that then as a technical manager the architect does less and less architectural work and does administration, putting out fires and ultimately more golf. The result is an architect that is totally out of touch with what he or she really enjoys doing.

How to stop the Architectural Pied Piper

I don’t consider myself one of those people-people and can’t really provide input that is of a general nature – you can go and speak to your own people-people about that.

The first thing to decide is if you want the people with experience around – sometimes you may want to cut out the dead wood so that you can finally replace the token ring network. This can often be the case with architects that are simply looking backwards instead of forwards – the kind who look back fondly on visual basic 6 and print out their emails.

Also you need to establish why you want to retain the experience – it could be that you need someone who knows all the history of the legacy systems so that they can be used as a reference guide for all the hacks and workarounds that have been put in over the years. That kind of person may be quite happy being a manager of a maintenance team and does not want any architectural responsibilities.

If you want to keep good, experienced architects, you need to create an environment where you can realize their benefit. A good place to start is to define the architectural role carefully – not simply employee specific roles and responsibilities. What is needed is a clear understanding of what architects do and how they fit into the IT department and it needs to be communicated more broadly. Although good architects are able to explain their functions to whoever they interface with, it would be a great help if all participants, from developers to business are clearer on the functions. Understanding functions within an organization is usually general knowledge – most people know the difference between say a sales manager and a financial controller – why should it be any different with IT.

For other ideas, look at the reasons for leaving above and find ways to counter them, such as:

  • Insist that architects have relevant current knowledge of implementation issues, but don’t insist that they code it up themselves or patch it into the network.
  • Bounce proposed approaches off architects and ask for their input. Most good architects will be able to provide useful pointers, anecdotes and long stories of things that you have not considered yet.
  • Involve your architects throughout the entire procurement process. If they rough up the sales person a little – let them. The worst that can happen is that they uncover some cracks. If the product is worthwhile and the salesperson any good they will be back for another round – hopefully having addressed some of the concerns.
  • Back up your architects and present them as key participants in decision making – if they disagree, ask them to present their reasons formally, logically, concisely and clearly. Good architects revel in such an approach.

In case you were wondering, I’m not some washed-up techie who is going through a mid-life crisis. I have been in software development for about ten years and been doing architecture for at least four. When I need to, I can out-code and out-deliver most developers on my team on the latest technology. I’m not leaving, although I if my current framework/platform (.NET/MS) becomes marginalised, I probably won’t learn a new one in as much detail.

To the architects out there – see what you need to do to stay in the game. To business – keep your great architects so that systems can be delivered.

Onion Architecture

Onion Architecture

By Shabbir Akolawala

Problem with Traditional 3-layer architecture

Over the years, 3-tier architecture has been the norm in architecting the enterprise architecture. There’s nothing wrong with n-tier architecture, but over the year, with library explosion, it has been difficult to keep up with just logical layer separation, where we are trying to solve different problem.

Let first understand the problem in following, conventional 3-tier architecture. In traditional 3 tier architecture, Presentation (UI) talks to business layer and business layer talks to Data access layer

Direct call to Data access from the UI isn’t allowed in the 3-tier architecture; as layers are stack one over another.

So far so good, but embracement of new UI architecture like MVC (Model view controller) find it hard to fit in the single layer constrain like UI shouldn’t talk to data access layer

Very easy for developers over time to put more and more business logic in the UI layer

Counter-productive to build your application on top of a specific technology that is sure to change over time

Impede with traditional architecture

  • Logic is easily scattered all over, locating code becomes a major effort.
  • Developers over time struggle to determine where code should go… DAL? BLL? Utilities?
  • Business logic has many tentacles extending from it (directly and indirectly)
  • Library explosion: Makes it easy take a dependency without putting much thought into it, and now it’s littered all over the code base


In order to solve, the problem, better way would be to invert the dependencies. This would loosen coupling between layers/component

Here comes the Onion architecture. In it application core layer consist of core domain entities, like model, interfaces, services, business logic which are related to business problem, and free from infrastructure concerns.

Onion architecture consists of three principles

  1. Core
  2. Infrastructure
  3. Dependency resolution

Most of the infrastructure concerns are outside your application boundary and are related to infrastructure. Persistence data concern (RDMS, NoSQL), Notification concerns (Email, SMS), transport security concerns (http, SSL), Authentication (windows authentication, form). These concerns shouldn’t dictate the business rules and shouldn’t creep into all the layers. Hence, all infrastructure components are represents via abstract interface in Application Core.

Concrete implementation of the interfaces would be injected into business and domain services at the Runtime via dependency injection at runtime.

Onion architecture uses to draw application/system using concentric circles, can only take dependency on something provided in an inner layer.

It has following triads

  • Direction of dependency is toward the centre
  • Externalize all technology related code
  • Push complexity as far outward as possible
  • Take ownership of your interfaces

RSC implementation

Onion architecture has been taken as architectural spike and has been implemented in ICT projects

  1. Approved Training Course
  2. Events

General benefits observe after following the architecture guideline

  • Solutions become clean with distinct line between the responsibilities
  • It easier to implement cross cutting concerns like tracing and caching without polluting the core methods
  • Business logic become guileless, straight forward and focus on domain problem rather than infrastructure concerns
  • It tranquil automate unit testing due to loose coupling of components
  • It easier to extend component without breaking the dependency