This blog discusses the impact of having solutions documented with no architecture behind it.
Deep thought, a super computer in Douglas Adam’s Hitchhikers Guide To the Galaxy was commissioned to find the ultimate answer to life the universe and everything, and after 7.5 million years managed to do so – the answer being 42. The mice were not impressed; deep thought pointed out that the real problem was that they cannot understand an answer when they didn’t really know what the question was. So they had to build a bigger computer (The Earth). There’s a little bit more about that at the video at the bottom.
In terms of time, that was a fairly costly mistake, and one that I see sometimes repeated in architecture design – it is directly relevant. Some people create Architecture Solutions, but its only really a solution if we can clearly identify what the problem is.
I’ve said it before – A solution needs to Identify stakeholders and ensure their goals and requirements are captured; along with their rationales. There is a need to show in design how the needs of all the stakeholders are met. If that’s not happening methodologically there’s a real risk something will be missed.
For a solution to have properly captured requirements, you need to know where the requirement came from, where it went to, what the requirement was and why it was. You then need to show how its been either realized in the design, or in some cases why it has not been included in a design. If you fail to answer any of those questions you will potentially force someone to have to spend hours tracking down the information later.
If I come into a project which only has a solution document it presents huge problems to myself as an EA – because I can have no confidence that the architects have full control of a situation. I cannot understand a full solution without potentially spending 100’s of meeting hours, in an attempt to build or understand a basic design. That’s effectively trying cover the work of dozens of architects and it really isn’t practical. That’s not really my job so more often or not it ends up in pushing back towards the project.
Some technical specialists with experience will naturally do a fairly good job at planning and implementing a design and just focusing on creating a solution document. They have seen the common challenges and know how to guide projects. Because these guys can seemingly pull solutions out of the air, its easy for people to mistake a technical specialist for a solutions architect. In organisations with poorly defined competency programs I have even seen the roles of tech specialist and architect confused.
The problem is that in this case you are leveraging the expertise of the individual in a way that doesn’t scale very well. It means you need very highly competent and expensive technical specialists. If you are doing this in a large organization the ability to quickly adapt and change as well as the ability to scale is compromised severely – because your architects lack the vocabulary and disciplines needed to talk with each other and properly manage requirements that come from different directions.
Its really painful to become the architecture lead of a project with 20+ architects only to discover that none of them are creating architectures, they are just writing solution descriptions based on discussions. Its hard to lead a team of architects when you don’t have the same vocabulary and in such circumstances is difficult to achieve tangible results. Its also hard to explain to management why architecture is not providing the benefits it should when you have so many architects on paper.
Do you have control?
At this point if you have architect in your job title and you work in a large organization, I would ask these questions:
How well do i understand all the developments going on in projects that impact your work?
How well do you know which standards your designs my comply to?
How compliant is your architecture to the needs of all its stakeholders?
Does your architecture design not only show what you need to implement, but how it should be implemented, and how it should be operated by who?
I have met architects whom despite being very competent, smart people, would feel a bit uncomfortable answering all those questions, even if they are routinely building architecture “solutions”. They are still excellent resources with a particular set of skills that provide value; and still have an important part to play in the role of architecture design, but they are not always architects.
Understanding the risk
If your solution doesn’t fully and clearly identify requirements in a way that’s easy to consume and is collected together in a single place, then I would challenge it. Risks are things that may impact your ability to meet your requirements. if you haven’t identified all your requirements clearly, then you have no way of properly understanding or managing risk.
You also have no way of ensuring your test and acceptance criteria are really fit for purpose, and may risk scope creep.
If you have architecture solutions without architecture design I would log at least one risk – that the architecture design may contain un-managed levels of risk and not be fit for purpose.
Now I have scoped some of the problems I will point out the obvious solutions – We have to do proper architecture design including requirements and risk analysis preferably following some kind of standard for description such as ISO 42010.
We need to ensure that architects are trained to do architecture, and expected to deliver architecture artifacts. If working in a line organization, for managers who do not understand the architecture roles, I would suggest they should also report to a lead architect. Those resources should be allocated time to do architecture properly, and the lead architect should directly contribute into their goals and job assessments. Failing to do this can denigrate the effectiveness of architecture. I can personally attest to how frustrating that can be.
And for Hitchhikers Guide To The Galaxy Fans
Now I have finished talking about architecture, Here’s a clip from the TV series where the mice are given the answer to the ultimate question. You will hopefully see the comparison between this, and providing a solution without a design.
I often get given parts of architecture and am told the architecture is complete. This blog shows the bare minimums I use for assessing completeness.
Here I am laying down some minimums I ask for before I consider architecture to be complete, in terms of the types of things I need to see. In terms of actual subject matter, because the world changes is may be that architecture never stays static.
It can be very frustrating to repeatedly be told an architecture is ready when the basics are missing, so I thought I would lay them down here for all to see.
Although I am speaking from my own perspective, much of what I think, and how I practice architecture aligns to standards such as ISO 42010.
Its worth noting that I will sometimes be a bit relaxed with how I assess architecture depending on who is giving it to me. I don’t want to lay down law so much as provide direction for improvement and avoid having to spend to much time in a cycle of reviews. This blog is written with architects that work for/with me in mind.
It’s not a complete architecture unless it clearly identifies requirements
Requirements should be in some kind of list, saying where the requirement comes from, where it goes to, who is managing it, the priority and why it exists. Often extra information around status is also directly available on a requirements list. It is not enough to say the requirements are in the solution description we sent to the customer. The solution description is normally a text document, and unless you pull the requirements out of it, its easy to miss some of them. Also the solution descriptions normally are very customer focused. There are a whole bunch of internal requirements solutions normally have to adhere to if we are designing something to be compliant with ISO 27k for example. Have requirements in a list, so we can address them one by one. Take a look at the TOGAF ADM Model – requirements management is at the heart of this model. Understanding needs of stakeholders is key to ISO 42010 as well.
It’s not a complete architecture unless it shows how requirements are met
Every single requirement has to be addressed by a solution or it is a risk or vulnerability; because by definition if you don’t address a requirement, somebodies needs are not being managed. Its OK if an architecture will not address a requirement – but that kind of a decision still needs to be tracked in your design; the polite thing is to agree it with the originator of the requirement or failing that to agree it with someone who has authority to make such decisions.
If you cannot show how requirements are met, the architects coming after you will have a hard time understanding why architecture decisions were made. This can, for example, lead to people innocently making changes at a technical level that breaks how things work from a business one.
ISO 42010 says that architecture concerns should be framed in one or more views.
It’s not a complete architecture unless its been agreed with the stakeholders
Your architecture should be identifying stakeholders – the people it provides value to. It stands to reason that means that how it provides value is of interest to those stakeholders. If your architecture doesn’t meet the stakeholder needs, it hasn’t succeeded. This doesn’t mean all stakeholders will always be happy. Quite often architecture may be an agreed compromise. A customer is not the only stakeholder!
ISO 42010 has some great examples of different stakeholders your architecture may want to consider.
It’s not a complete architecture unless it addresses the appropriate aspects.
I speak often about covering IT Aspects. Having a brilliant diagram of how different system components fit together is almost never enough.
We have responsabilities to follow regulation, and those fancy technical designs are often going to be operated by someone who didn’t design the solution. This means people need to understand how the technologies work. How we operate things, sell them, and implement them all need to be considered as part of design and communicated.
When this isn’t done as part of an architecture design you end up quite often with something that isn’t scalable. Sometimes what will happen is the talented technical designer will hold the hands of the people that will support things and for a while things will run OK. Over time, people change in the different roles, and what was once laid out clearly becomes less clear as the IT equivalent of Chinese whispers happens.
Of course because you haven’t built and implemented a consistent design people may do things in different ways, leading to cost overhead, a loss in scale-ability, trace-ability and a diminished ability to do any kind of real optimization or effective cost reduction.
It’s not a complete architecture unless its been documented as one contiguous solution
If you do not have all the parts of a solution documented together in one place, or at least tightly connected to each other, its very easy to lose things, and to lose track of your solution. That doesn’t mean everything is in one word document. If you are using word to describe your solution then its OK to refer to other documents containing information you rely on – such as the requirements. If we do this though, we have to make sure that a) everyone reading a document actually has access to all the associated links, b) that information across the different information sources is properly versioned.
When you don’t properly maintain versions then you can end up in a situation where a solution refers to a requirements Excel, and someone else developing requirements may make changes that your solution doesn’t address, leading to a great deal of confusion for anyone reading your work. A good architect will be aware of the company documentation standards, and will be also designing solutions that cover whichever modelling standards are in place.
It’s also not OK to make decisions in meetings and not document them, or only documenting them in a set of meeting minutes. Its so very easy in those cases for a decision made in a meeting half a year ago to just disappear.
ISO 42010 makes mention of tracking key decisions in a log. I find that keeping things together relating to a particular work stream makes a lot of sense. It doesn’t have to be in depth – just knowing the date, the person or people working on something – and what they achieved – can save a lot of time when new people are on-boarded or when questions are raised during escalations.
Anyone that’s read my blogs or knows me, knows that I prefer to have my architecture be in a model, rather than documents.
Summing It Up…
If you have a good technical solution – that’s great. I do not argue that a technical diagram detailing how servers connect to different networks is not a valid part of architecture. It is. There’s also an argument that architecture always exists whether it is documented or not. Take a look at my blog on Designing Architecture Through Document Templates if you are interested in that..
The point i really want to make is that in order to have an architecture solution, you need to have clearly identified & scoped the problem, and show exactly how it is that you are keeping promises to your stakeholders, Not doing this will more often or not lead to extra cost later on down the road.
Its the most natural thing in the world to want to promise things to customers to keep them happy. This blog discusses the dangers of that.
There are a couple of scenario’s I have seen occur many times in my career. Sales and customer teams unintentionally causing harm while wanting to keep customers happy.
Keeping Promises – The Catch 22
There’s a circular downward spiral that can happen:
Teams have trouble meeting customer expectations
To make customers happy they make promises that are hard to keep.
Because those promises were unrealistic, they loop back to step 1.
Its very important promises made to customers are realistic and can be delivered. For Example, If an architect says something will take 20 months to deliver, Its for a reason. A customer team should not agree with the customer to deliver in 12 months, without the solution design being revised.
Its important to re-plan because its most likely not as simple as throwing extra resources into a project or working overtime. Although efficient architecture can make scaling resources for projects a lot more cost effective, often architecture designs aren’t perfect which leads to a cost overhead. There are often dependencies at work. For example if an architect says migrations will take 2 week that estimate may have factored in things such as the amount of data that needs to be migrated and transfer speeds between systems.
If the customer needs to then do things in one week – the architect has to be consulted. It may be possible to meet the deadlines – but, for example, it may mean changes to the solution. Upgrades of hardware would mean extra costs, a different plan, or another mechanism for transferring data. Maybe using disks to transfer rather than over the network is an option. If you change the transfer mechanisms other risks come into play, and the impact on the end user may change.
Somebody Else’s Problem
Sometimes I have seen it where a the delivery team are just not consulted by the front facing sales or customer teams.
People are motivated to meet their own targets, and sometimes targets and goals for individual teams do not factor in a need to work together.
For example, a sales team may have annual sales targets. This can motivate them to make promises without considering the delivery consequence. If you measure and reward a team based on getting customers to sign they will do what it takes to achieve that.
It is a very different case if metrics are put in place to tie together the success of a sales and delivery team.
Adopting A Culture Of Collaboration
If a sales and customer team makes unreasonable promises, it will ultimately cause harm in a few different ways.
Failing to deliver erodes trust; conversely becoming a trusted partner really opens up doors of opportunity.
Putting delivery teams under excess pressure destroys morale – bad morale destroys productivity and you end up with long running projects that have very poor retention of staff. At this point if you don’t have good architecture in place your costs can also skyrocket as unnecessary meetings and fact finding missions start to happen as people need to catch up and be on-boarded onto a project.
Costs also start to balloon because its likely that you end up customizing standard solutions when you don’t need to.
Its very important that sales and customer facing teams collaborate with architects. Don’t forget architects are there to solve problems, not create them. If a sales or delivery team is going to ignore or override what an architect tells them then that’s likely to have consequences.
Summing it up
A good architect designing architecture should be considering the needs of all the stakeholders and identifying risks to the different stakeholders as they happen. They are not there to make the life of the sales or customer team more difficult – although sometimes it can feel like that when they are pointing out lots of potential risks. There are internal risks of course that we do not expose out to customers, but its good to have an honest opinion.
There’s no shame being in a meeting with a customer and saying “I understand your needs, but before I commit to these deadlines I need to talk to my architect team”. There are sometimes times when sales need to agree to things to win a bid – but they should still talk things through with architects. Sometimes seemingly small things can significantly impact the viability of an entire business deal
This blog details 10 issues I have experienced in the past when organizations I have worked for, or with, have implemented large scale change
Recently the Company I work for Tieto announced a merge with Evry. We will become TietoEvry. Over the years I have seen many mistakes happen in different companies making large scale strategic or operational changes.
I would hope our organization avoids these issues in the run up to our new merger and I would hope anyone considers before implementing large scale change.
1. Planning Strategies
All too often I have seen big changes happen without proper planning; management have an idea, may have a few focus groups, or get outside consultancy and a new direction is born.
The big mistake can happen when this is done without fully understanding the impact of change, which is where enterprise architecture comes in. We have a whole range of skills around understanding business motivation, and analyzing business risk and change. Our modelling techniques when properly applied can enable us to help management understand the true impact of change. A good Enterprise Architect can act as the right hand of the business stakeholders.
If you build a strategy without involving enterprise architecture (and this does happen) then you may be limiting its effectiveness. You may be implementing an inefficient plan, or in some cases even an untenable one.
Its important to involve enterprise architects at the beginning of any planned organization change and throughout it. A good EA has tools, and insight into the change process and can provide all manner of methodologies that can help.
2. Solving the Big Problems
Before releasing a major direction change for a company its important to have solved the big problems – and to have a plan not only on what you want to do, but how it is you want to do it. In defining the plan to move forward its important to at least have a partial idea of where you are – understanding the current state helps you understand how to move forward into the future.
I previously wrote on planning work with Archimate – Fundamentally the concepts I introduce could be used, but with large scale change its important to start building strategic layer thinking. I would define current and future state architecture as well as the transition between them – in ArchiMate terms this would be defining plateaus and plenty of implementation architecture. The time you spend planning ahead of time is small compared to how fast you can burn time when nobody in the organisation has clear direction after a strategy announcement and just waits and sees what will happen.
A good approach is rather than just announcing change and stating it will happen, engaging teams before hand and get them to help. Taking a conversation where you say “We are assessing a number of options – if we take this option, what would be the impact to you – and what would we need to do to make it work?” will help you see pitfalls that may not of been evident and it also gives a level of engagement and commitment to an idea.
When merging companies, or making changes that will have major impacts on the jobs of employees, there are of course some limitations to how far you can take such an approach. Even if you cannot engage the entire company, a good enterprise architect will help.
3.The Aspects of Architecture
I have spoken about the IT Architecture Aspects before. As with all architecture changes, a new strategy necessitates us to think of our architecture aspects:
Processes & Roles
People & organization
Information & Governance
Tools & Technology
For each of those areas we effectively need to explore what, why, who, how and when. This can be approached with different levels of methodology. Some EA’s model these aspects using languages like ArchiMate and are able to give detailed analysis of the impact of change across the different aspects. Its very easy to miss key elements when you are not thinking about how the different aspects interact with each other.
4. Feeling Engaged
Its important for teams to have a solution minded approach to issues, rather than a problem minded one. I have to be careful with this one myself; I tend to think in terms of problems – not because I am negative, but you do need to identify a problem in order to be able to solve it. If a team has a problem the same team should also think about potential solutions, or we can handle it as an architecture concern.
Its amazing how a few individuals can derail the success of a strategy. At one point I started running a new architecture team that was implemented amidst many other changes. In order to manage the scale of change I decided I needed to engage a small core team of 5 architects and they would manage the larger team of around 100 people. I was distributing authority, because I am only one person. My plan would have worked well, except for one person. I would set direction for my team on a Monday morning, and in the afternoon the core team would set direction for everyone else.
What happened was one person in the afternoon meeting would complain about everything. Effectively that one person turned the entire strategic focus from being solution oriented, to being a firefighting one. It was negative and it was hard to get people engaged in creating a positive change. My core architects were stressed and every little thing then began to be questioned. Even more time was wasted.
In the end because I had to manage that problem and for a while my work was significantly increased. I didn’t allow this to continue for long, but my point is, that if I had known the trouble spot to begin with and taken efforts to get that guy on board with the new strategy, the strategy would have been faster and easier to implement. If one persons argues an hour in a meeting you invited 100 people to – you have lost 100 hrs of time and will have collateral damage.
There’s a balance to be had. Where you see a negative influence, you need to deal with it fast – preferably in a positive way. A passionate person can be your undoing, but when you manage to get the same person on board they can be your biggest advocate. Its good if you can identify passionate people up front.
5. Role Management
When I look at different companies and reasons for failure of strategy execution sometimes it can be traced back to Human Resources / Line management processes and adherence to them. Any job role has a set of expectations and those core role expectations are the ones that need to be assessed and measured. When this isn’t done what can happen is over time as the organization changes, roles change. This can give an enterprise architecture headache as you see an organization that appears to be fully staffed in different functions but in fact isn’t. When trying to decide a new team structure this can be a problem.
For example if technical specialists become architects without proper training and assessment you end up with a group of architects who will know technology but not have the skills to be able to fully describe an architecture or manage it. The transformation from role to role may have happened for a variety of reasons.
I once in the past came into a project with over 40 architects, of which none of them could actually describe architecture outside of creating basic technology views in Visio.
If you were to run a team with 100 architects, and you think the workload only needs half that, last thing you would want to discover is that in rationalizing teams you have broken other areas of the organization because the job those resources were actually doing was not what you thought at all. Before making such decisions its essential to really understand what all roles and responsibilities in the organization actually do.
6. Consistency in leadership
For change to be effective it needs to be understood and aligned within the leadership of a company. When a CEO announces a change of course everyone in management normally want to do the best to support it, but sometimes their own personal goals and targets can restrict this. IF a CEO gives a set of goals to hes leadership team the leadership team needs to filter those goals down to the level below them. and that level needs to cascade the relevant goals further down.
I have seen in the past in some companies goals at the top level that look very different to the lower levels. If a board member has 10 goals around growth, and development in different areas, but his/her direct report only has a financial target – much of what was intended will be lost. Even if PowerPoint presentations fly around the place with all the original board goals. Much of what is in PowerPoint gets forgotten over time. The formal review mechanisms need to include the goals from the board in some form; if you are expecting the subordinates to meet them. The formal review process is actually what impacts peoples earnings and career development.
In one company I created an architecture view that showed 5 levels of management together and their goals, and only financial goals existed below the third level. I asked my manager at the time why this was, and was told that the management didn’t want targets that they couldn’t easily measure, because it would impact their bonuses. This was bad.
If your HR processes are clear and measurable, and someone takes the time to ensure that goals are aligned as we filter down an organization then when change comes we can more clearly ensure that change is effective. Wen building a strategy clear expectations need to be laid out to every level of the organization and if need be working practices and processes revised.
7. Unclear HR
People tend to stick with doing what they are comfortable with but unless goals change and people understand their own personal role in a new strategy people will not be fully invested in it.
What can be worse is when the change then happens – often some roles disappear. This is where hero’s are born – and a hero in enterprise architecture is not always a good thing.
Heroes do their best to mitigate the chaos around them by assuming the responsibilities of roles that do not belong to them and seemingly get things done. I have a love/hate relationship with this. I applaud the effort and intentions. However, this can break things in many ways for many reasons including:
Roles informally transform: if a role informally transforms it means you have created a deviation from the intended strategy; and the way the company is something else. Your organization is not running as intended.
Processes start to break: At this point you will start to detect the issue if your processes are properly measurable – because you will see they are not running as anticipated; the correct people are not doing the correct things. The outcome may appear to be good but the working practice is unlikely to be efficient, and where you aren’t following process you are likely creating risk
Understanding resourcing hot spots becomes impossible, because people are covering them up. For example if a sales team suddenly looses the services of a translation team, they may have people who can do the translations in their own team. If they do that without properly escalating out the fact they are doing that work there are a couple of possible issues –
Firstly they might not do the job as well as a professional service.
Secondly, they have then become unwittingly accountable for that translation.
Thirdly, they have added to their own workload and stress. I’ve seen this break good intentioned people.
Fourthly, The line manager may understand this change in role but if its not formally built into the role then in adding the responsibility to the resource means the focus is suddenly shifted from the intended job role to something that is invisible to the organisation on a whole. If that same resource is spending a week doing translations in a sales case, he is also spending a week not doing sales.
Fifthly, This isn’t scalable. If a sales resource is bridging the competency gap filled by another missing role in the organization bringing in another resource to assist won’t be as effective as it should. Different heroes will extend themselves in different ways and this becomes quickly immeasurable.
In bad situations I have seen line management become reliant on heroes. If you are a line manager and can only use one or two of your key resources for a specific task the chances are something is wrong. Either your operational processes are broken, or your HR processes are. As a line manager this has to be escalated and actions must be taken to rectify this, or what will happen is over time, you will lose your hero as they become overwhelmed; and you will be left with worse resources, until the quality of work becomes so low that the continuation of business is untenable.
This may sound a little controversial but we need to eliminate the need for heroes. If our strategy ensures we have clearly defined roles and KPIs, and we put in processes to ensure they are followed the need for heroes is significantly diminished.
Its important to be aware that having measurable KPI’s in an organization doesn’t mean you become any less flexible. It means you are keeping track of the things that matter. Its possible to have a good balance of discipline and flexibility.
I can imagine some people thinking what I said about Hero’s is wrong – because we all have responsibility to do what we can to further business right? Yes we do. but there’s a right way to do it. In an organisation I would say everyone has a responsibility to identify and escalate risk where they see it – I would also say, sometimes we do need to step outside our roles and get our hands dirty when its needed. Of course communication and collaboration is important. Collaborating with our coworkers to help them is important – but we should always be mindful of our own roles and goals, and of the process.
9. The Importance Of Process
Process is important because it enables us to scale, have common direction and measurement, whilst managing risk. Sometimes process is not well defined which needs to be addressed. When a professional escalates they do not normally just complain; its far better to offer a solution rather than a problem. Its also important to have perspective. Everyone thinks that their area of business is important, but its rarely as nearly as important as the business of the whole organisation.
Properly defined business interfaces need to exist between different parts of the organization, and between the organization and the outside world. All these things need to be measurable. If you are running a business with many service areas, as well as the underlying processes, you need overarching processes to hold those units together – not only the company level standard processes, but also processes that address the end to end needs of the customer.
When transforming the organization you need to also be considering from the outset how you are changing process. If a process is not communicated well, is difficult to follow, does not cover all the use cases necessary, or simply doesn’t work, or isn’t helpful these are all failures of process design that need to be addressed by a process team. Processes can be agile and flexible if they are well defined – they don’t have to be a monolithic. Process often gets a bad reputation because its often poorly designed and implemented.
10. Communicating Change
The first thing I would say about this, is do not talk down to your resources. Treat people with a level of respect and intelligence and they will, to an extent, do the same. Of course there are legal implications of what you can and cannot communicate, and over communicating can be problematic too. If you stress people to the point they are worried about their jobs efficiency goes down unless in the same time you are communicating exactly what needs to be done in order for people to keep them. A plan that is effectively designed between management and an EA will go a long way towards quietening discontent.
Having a plan defined with architects before announcing huge changes goes a long way to calming fears. A company can loose many man hours if they announce the change and then do not follow up with direction as to how the change will be handled and implemented quickly afterwards.
The direction “Business as Usual” has a limited effectiveness. Uncertainty is a productivity killer. People sometimes will worry – they will stall – they will be reluctant to implement some initiatives because they will be concerned of effectiveness.
This blog lists the 7 biggest frustrations I that have experienced in 20+ years of working with architecture and some of my approaches to tackling them.
The frustrations I speak of come from different companies I have worked with over that time. I wanted to share these in hope that it helps other people; they are not frustrations I feel now!
1. The Idea Architecture has to be “hard”.
In my career i have spent a lot of time dealing with people who don’t embrace architecture because they see them complexity and not the benefit. It can be a bit overwhelming to the uninitiated. The best architecture is most often simple architecture; or a complex architecture that has been broken into consumable views. Sometimes its perceived as complex to do a formally structured architecture because architects have their own ways of doing things, which are not based on formal methodology, so there is a learning curve.
The more architecture you do, or the more you model with a language like ArchiMate, the easier it becomes. In some cases I’ve seen some architects spending much more time complaining about creating architecture than it would take to learn and do architecture.
To mitigate this I break things down into small consumable chunks. You may have noticed many of the ideas and things I present on this website are often simplistic – or miss some elements completely – For example in Planning Work – I didn’t mention Plateaus or Gaps. This is because when I talk about work planning I want to start with basics to get going. Sometimes you can achieve more by asking for less. Later on once people are more comfortable with some things I may introduce the next layer of complexity.
I give a lot of time in 1 to 1 sessions with architects – and I have a few people I mentor and spar with. To develop an understanding of architecture happens best when you have someone who actually has some experience and can explain not only what we do and how we do it, but also why. Those people I have mentored have gone on to teach many more architects.
2. Stakeholders not giving commitment
This one can be tricky, especially if the managers I am dealing with are ex technical people with a view of how things should be, what they want to do and how they will achieve it.
In immature organisations these guys want to just bypass architecture all together in order to get something out the door, or see architecture as just creating a technical view.
If stakeholders and resource owners don’t understand the value of architecture, and an EA is not a direct line manager of those architects, then architecture doesn’t get done. The consequence can be any or all of the following:
More incidents or major issues
Poor compliance to standards & huge costs when auditors come
Poor scalability & automation
Poor business agility.
The best approach to tackling this is to show value directly to your stakeholders, by taking a few of their key problems and helping to solve them through architecture. You have to engage the stakeholders directly. At one point previously I had an architecture team and trained them in architecture discipline and had constant trouble with achieving anything. This was because although the architects saw value in what we were doing this value wasn’t getting properly communicated to the stakeholders, so I was never getting enough time commitment from the stakeholders that owned architects to show much benefit architecture can bring. I would say its better to engage stakeholders directly.
3. Business not Understanding the function of an architect.
Sometimes people get the Impression that architects just do technical solutions – which isn’t even true if they are technical architects. There are of course different types of architects with different functions – but in general, you have to understand the word solution.
To build a solution you need to frame the problem. An architecture isn’t complete unless it shows the requirements the solution must meet, how those requirements are met, and then the final solution. Requirements come from all directions – not only from the technicians themselves.
If you aren’t considering the needs in terms of the different aspects of architecture then its very likely your solution isn’t fit for purpose, If you are lucky at this point the technology is fit for purpose, but all the costs and the impacts of the changes haven’t been considered because you haven’t managed stakeholder concerns. When this happens inevitably there’s a cost overhead in communication, and often an additional overhead as we have to change the technical solutions when new things are raised as issues and you have general inneficiency.
Sometimes I have seen the opinion that project managers manage requirements; which is partially true. Project managers are concerned with understanding project status, and to do that they need to understand the status of requirements and their realization. For that reason requirements management may be laid down by a project practice. In organizations with immature architecture practices this leads to project management organizing and managing requirements. This can lead to overheads and challenges for the project managers who then need to start to get very technical to understand requirements realization. If a project manager needs very specific technical knowledge it normally means an architect is failing to do architecture somewhere.
This can be a disaster in large projects because there is an order to requirements and services. I have seen in some cases project managers take requirements and just assign them to different teams then each team takes responsibility for those requirements. This adds can be problematic because when a project manager manages the requirements work, the project is the focus, and not the development of the solution. In large projects this can mean architecture is worked on in isolation by different teams and when the pieces are put together at the end sometimes they don’t fit.
In addition to that, customer requirements and project requirements are not the only requirements that need to be managed – there are non functional security requirements, architecture requirements, as well as requirements from other teams. They all need to be managed together, and an architect ensures this happens by applying architecture discipline.
4. Not having architecture discipline
Doing architecture once you know how is not hard. Its getting to that point that it is second nature that can be tricky.
By architecture discipline I mean giving the time to do architecture things. Architects need to manage concerns, document decisions, and and either model or document things. If they aren’t given time or don’t give priority to those things bad things happen.
Firstly the value architecture brings to the overall organization is significantly diminished. There’s a lot of benefit you can get out of an architecture model. Not tracking key decisions in one place, or tracking how requirements are being managed leads to a huge overhead.
Firstly if someone else is trying to understand whats going on – they cant. It means extra meetings, extra time, extra cost.
Secondly over time we lose reasons why things happen. Architects and other project resources change. Even if they don’t – sometimes remembering why i did something yesterday is a challenge, thinking back to three projects ago a year back, is hard.
A third point here is that we lose the ability to collaborate. Its possible for a group of architects to work together – one on technical design, one on standards compliance, or to break down a project between all manner of dimensions. You lose the ability to do this effectively if you do not document.
Time has to be given to do full architecture, or development work may be inefficient or may drag on for extremely long time periods due to bad scoping.
Many people consider proper architecture discipline to be a pain in the ass, but it is MUCH cheaper than having to waste time correcting things after. Correcting things will take a lot of people a lot of time.
Its possible for good technical specialists to create end to end solutions without practicing architecture discipline. But when that happens you are suddenly reliant on that single resource, and you will find that adding extra “architects” to a project wont help get things finished faster – because the architecture doesn’t scale. The extra resources will have a diminished return because they simply dont have the knowledge of the people in the project and no way of getting it, other than to ask a lot of questions, that they may or may not get answers to.
The only way I manage this is to be clear in my communication with stakeholders. To identify what is needed in terms of discipline, and the risks of not having it.
5. Not having the skills
I’ve spoken at length about the benefits of different things, such as architecture, and ArchiMate. Architects need to understand how to structure and communicate architecture.
A common architecture language such as Archimate is essential. Its not enough to understand what a view looks like, its essential to understand the meaning of each element and meta-models that are being used to structure an architecture. Do that – and suddenly communication can become a lot more efficient and we can start to share and communicate architecture, and leverage some benefits of scalability.
Technical specialists are not architects and shouldn’t be confused. They are really important, but rarely do they think far beyond the borders of technology. You cannot take someone who’s worked 10 years in technology and just expect them to suddenly understand everything about architecture methodology. Anyone who has ever done any fly fishing will know there’s a lot of difference between observing it and actually doing it – even if you have spent 10 years fishing with a reel.
If you want to really leverage the benefit from architects they need to be trained, and they need to be working the same way. In situations where a company has several methodologies a mechanism needs to be put in place to align them.
If you don’t train architects to understand your common languages such as archimate consistent communication is challenging. Its much like putting 4 resources in a room that speak different languages and asking them to collaborate to solve a complex problem. As a Swedish Speaker i may be able to understand a few words of German, or as an English speaker I may have to figure some kind of sign language and resort to a pen and paper. English and Finnish are very different to Swedish and German. I may be able to figure out whats needed and solve the problem, but I may not be 100% accurate, and it would have taken a lot of effort and frustration.
Just don’t do this, and communicate to stakeholders the reasons its a bad idea.
7. When you see all above.
Sometimes there can exist a situation where all of the above can exist. When that happens its very hard to lead an architecture team. It can be hard to get management commitment for resource time to do anything because they don’t see the value of architecture. Because they don’t see the value, and they don’t prioritize it, discipline isn’t practiced so the value is diminished. This leads to architecture being left to the end of a project, which effectively kills off most of the benefit.
In these cases all I can say is chip away at the problem one frustration at a time. We need to be close to our stakeholders and to help them understand the value we as architect can provide to them.
Architecture isn’t the enemy of management. Its there to enable management, not place roadblocks for it. It’s only slow and ineffective when its not fully embraced. Once you have a good architecture team that is committed, running common languages, and a good repository, you can start to provide business intelligence and tools to management that can help them in ways that many managers I have met in the past could not imagine.