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.
Sometimes I see architecture left until the end of a project. These 8 reasons are the reasons I normally try to push for it earlier.
There have been times in the past where I have been pulled in at the end of a project and told that the project has implemented a technical solution and there’s a requirement by the customer for it to be documented and when that happens I get a little sad inside. In large projects one person never has all the information. This blog is from personal experience from working at different companies over the last 25+ years.
Its worth mentioning at this point that design doesn’t all have to be done at once in a waterfall fashion it can be agile. I will talk about this in later blogs.
Documenting architecture always has value, but much of the value you would get from an architecture practice has gone if you start doing architecture at the end of a project. The bigger the project the bigger the problem. Lets get started:
1 – It takes more effort doing it at the end.
When you do architecture at the end of the project you have to take time to understand everything that’s happened. This includes understanding how requirements have been realized and what decisions have been made
As you start to understand the scope and concepts behind a solution questions arise. I might go to one person and ask the answer – they typically wont know. or may have part of the story. They lead me to other resources and it could take me hours of time just to find out why a single decision has been made.
If a team had been working together on a single architecture throughout a project you don’t burn that investigative time trying to understand things. It’s not always obvious what necessitated a decision, so its important to track decisions in a single place.
2 – Its expensive
Time is money – exploring the rationale behind decisions and understanding whats happened at the end means having to engage lots of people. If an architect has a meeting with three technical specialists for an hour that’s 4 hours of work time. When they don’t have the answers to hand – they have to write emails, contact other people, and come back to the architect – that’s also burned time. If the decisions had been put into an architecture as they were made, in some projects its possible to save hundreds of hours.
The same idea applies with things like requirements realization. If you haven’t shown exactly how each requirement has been realized in architecture you will have to investigate each one. If you are in a project with a 1000 requirements and spend 15 minutes investigating each requirement then potentially you would have to spend 250 hrs just figuring this out (more, if you consider you need to engage other people).
Map the requirements at the beginning of the project and make sure you create some kind of requirements realization within a project. Keep a log of all the decisions made, together with the activities taken around each requirements together in one place. This extra effort will save time and money as a project moves on and resources come in and out of projects. It will kill the need for new architects (or other people) having to “investigate” to understand status at the end of a project and will reduce the number of meetings you need during the project.
3 – Its hard to build well under time constraints
At the end of a project there are normally time pressures because people want to shut things down.When I am having to investigate the architecture designs and their rationales, I need to take time. If organizing a meeting to understand how we realized one requirement takes an hour, and may not yield the result – other meetings will need to be scheduled in. In a situation when you are given a week to deliver a design near the end of a project – that time disappears very fast if you need to have multiple meetings and rely on peoples availability. This puts deadlines are at risk.
If we are building the architecture throughout a project there is no rush at the end of a project.
4 – Information gets lost
If decisions are made and not recorded in an architecture information very easily gets lost. In large projects many people are involved – sometimes resources get replaced over time and we lose information on why decisions were made. Sometimes that information is recorded but we don’t have access to it. If you have a large project spanning 6 months, that is running a project meeting every morning where they make decisions that’s potentially 120 sets of meeting minutes – assuming those minutes are kept properly and all the information on decisions is available you still need to sift through it. Of course some people make all their decisions in email, sometimes people leave the company, some also forget or don’t write things down.. In these situations you have real problems.
Keeping architecture concerns and decisions documented in a work log as part of your architecture design process throughout the project mitigates this risk. Having that log available on a collaborative platform is essential. if you have to take a conversation in email – paste that to the collaborative log too, so everyone knows everything that happens and there are no hidden caches of knowledge.
5 – You find things that are missed
When you take a structured approach to analyzing requirements and creating a requirements realization view for your solution, things don’t get missed, because an architect is guiding work. This is one reason why we do architecture design in the first place – to make sure a solution is fit for purpose. I’ve often seen functional requirements well considered by a technical team but non functional requirements missed. A technical team tends to focus on things like getting a server up and showing a tangible result.
If you come to the end of a project and suddenly realize the technical solution doesn’t meet your requirements, you are in a bad position. It’s too late to rebuild or change technologies. You may end up having to compromise quality just to get the project ended, or investing a significant amount of time and money re engineering or rebuilding a solution.
The earlier you do a requirements analysis the earlier you find gaps. The hard and sometimes boring requirements analysis part at the beginning of a project is essential. You must make sure that every requirement is realized in a view. At this point you should be also ensuring every requirement has an owner that is managing it. The project managers can then more effectively chase up project status without having to call lots of expensive meetings.
6 – You’ve lost the benefit of concerns management.
There are two ways you can approach things. You can put out a fire in a burning house, or you can stop the fire from happening in the first place, by taking away the matches from the idiot that likes to start fires.
When you are doing architecture properly you are identifying and managing risks before they happen by applying thought and designing things to stop issues from arising. A design uses the shared experience of all those involved to avoid problems rather than the experience of individual resources. Of course you can also reuse designs, but that’s another story.
On the flip side, you can leave implementation of projects to technical resources. and manage concerns as they happen. When this happens you have an escalation culture. You normally end up with managers and a lot of emergency meetings to handle problems, often after the project is implemented, leaving a sour taste in the mouth of both operations and the customer. This is very expensive because its a lot of burned meeting time because you are handling the after effects of a fire happening; which also includes a level of damage control. If a house has caught fire several times during a project the damage has already been done. I’ve seen before entire platforms have to be rebuilt because technical teams have rushed to implement a solution without realizing the requirements or dependencies of other systems around them. I have also seen the same problems reoccur.
Concerns cannot be managed at the end of a project because you cannot go back in time to fix them. The only thing you can do that’s cost effective is manage them as they happen or suffer the cost of potentially needing to redo things.
7 – It ends up frustrating people
When you have the end of a project in sight you want to cross the finish line, the project don’t want to have to deal with an architect coming in at the last minute and finding holes in their work. It frustrates everyone, architect included. If you have left architecture to the end the chances are the budgets are depleted and people are exhausted through overwork because the plan that was executed wasn’t designed and work wasn’t properly estimated. The last thing anyone wants at that point is to realize a technical implementation is not fit for purpose when they cant do anything about it – thats demoralizing.
8 – It results in lower quality
When you consider everything above you will realize at the end of a project to get architecture documentation out, you are going to have to compromise. This for me personally is very hard, because I always want to deliver the best. It may be that the documentation will end up at a high level, or it may be that some concerns will just have to be accepted rather than mitigated. It might be that we need to make assumptions about why things were done, or that we don’t get to model our solution because there just wasn’t enough time. The team may have made costly mistakes during the project. At this point you have ran out of time to address all the concerns.
Its very likely that the quality of architecture will be lower if you used the time at the end of a project just to document architecture, rather than following an architecture practice during a project. Its also likely that because of this approach there will be issues arising once a project goes into service.
If you have viewed architecture as a documentation exercise at the end of a project the chances are that what is implemented doesn’t address all of your own internal non functional requirements, the customers requirements, or other stakeholder needs – because the time at the end of the project was focused on describing what has been put in place rather than what really needs to be put in place.
Architecture and security non functional requirements normally exist to ensure we meet the standards our companies promise, they are designed to protect the company, to mitigate risks risks. They also may address the needs of internal stakeholders and may have been put in place to ensure we learn from the mistakes that our predecessors have made. . If we haven’t designed a solution to meet the needs of all of our stakeholders, then we may well see the same issues reoccurring time and time again.
There’s no worse feeling in the world than having to present forward an architecture that you cant justify or isn’t as good as you would like it to be, because of things that were outside of your control. In such cases I think its always important to be honest, to present the architecture, and also the concerns that you have on it at the end of a project so they can be addressed by other architects or your quality team.
To raise quality we also need to raise awareness. architecture may be difficult and laborious at times, but as I have mentioned in this blog, people need to know the benefits of not leaving it to the end.
When looking at ArchiMate diagrams its easy to miss the fact they are part of a model, and not just pictures. This blog addresses the difference and demonstrates some basics around models.
Last week someone was commenting one of the views I demonstrated in a blog, and pointed out something that didn’t make full sense in the diagram but had been addressed in the view documentation. Its very easy to forget that we are not talking about pictures when we speak of ArchiMate models. In the blog my ArchiMate views are just images. I wanted to show some practical examples and discuss this.For anyone that doesn’t actually do modelling, but interacts with those of us that do, this blog is for you.
Before I get started its worth mentioning that a view and a viewpoint of architecture is a concept that extends beyond the modelling language. We tend to talk about views visually, but the view taken from a specific viewpoint could expressed in writing if we wished it to be, but you would miss the benefits of modelling elements and relationships with a tool.
“a graphic design that explains rather than represents especially: a drawing that shows arrangement and relations (as of parts)”
Of course there are many dictionaries but they all follow a similar pattern.Technically Figure 1, is both a view and a diagram. On this website its a diagram, which is a representation of an architecture view. the actual full architecture view has a lot more information in that is represented in figure 1.
Of course we can just use something like Paint or Visio to create a view like above – and it has a lot of value, but in those tools are for visual representation, and not modelling.
Figure 1 is a fairly self explanatory made up view which gives a level of information by itself. But it doesn’t tell us everything. I will show some of the things that differentiate pictures and diagrams from an architecture view in the rest of this blog.
The first thing to show is that views can have their own documentation – Figure 2 shows this – I have selected a view and you can see its documentation in the field below.
Of course if this was a real view I might also have provided links in the documentation to the organization chart. Although the view documentation is short here, it helps set the context for the view, and does provide some valuable information.
Individual elements or relationships can also be documented:
As well as elements having documentation relationships can:
The relationship type gives you an understanding of what kind of relationship the elements have but it doesn’t tell you why. That’s something I will typically do in documentation. This is particularly important when it comes to documenting less defined relationships, such as associations.
The point I am making is just looking at the diagram does not give you a complete picture. Some tools will allow you to auto generate documentation:
Many tools allow you to connect all kinds of metadata to elements & relationships, and allow varying degrees of customization in the example below you can see a references link I added:
Its very tempting to add lots of metadata to a model because you can, but i tend to think carefully about the value of any kind of information I would want to maintain.
Some tools such as Enterprise Studio, allow some pretty advanced analytics depending on the information you store with the model.
Navigating the model
The main thing that sets a modelling tool apart from a visual tool like PowerPoint and Visio is the fact its a modelling tool. We can navigate each element and see its relationships and the different views it appears in. The tool stores the elements and relationships as a fully relational model
Auto generating views
Lets say for example a stakeholder came to me and asked me to tell them a little bit more about what an enterprise architect is – With some tools I can automatically generate views. Take a look at a view I generated literally in 5 seconds:
In previous blogs I have used the enterprise architect role, and because the modelling software knows all the roles and relationships between each element in a model, and the rules for modelling in archimate we can very quickly create something meaningful.
The more work we do with our models, the more value they can bring us.
An architecture view is a view into a model. Figure 9 shows our auto generated view but on the left hand side you can see in the model browser that our model package contains many elements that are not on this view (because we created this view to only show actor cooperation’s to the enterprise architect element)
The model package contains many elements, views, and relationships. You see them on the model browser. You could theoretically take all those elements and put them onto a view:
Theres too much to remain readable on a normal screen – and it doesn’t make sense to show our architecture in a single view. This is why we break down architecture into multiple views, created for people interested in its different aspects.
To put in simple then. a view is just a small part of a model we are communicating, As you can see, the view in Figure 1, would be part of something much bigger.
So we can see that models have lots of elements and relationships, and different people have needs to see different things. View Points define which parts of an architecture we look at. A viewpoint definition tells us which types of elements we are interested in, and which types of relationships are allowed between them. There are many standard viewpoints defined in places like TOGAF and the Archimate Manual.
Figure 8 was an automatically generated Actor Cooperation View. It was generated from a Archimate 2.1 Viewpoint. The viewpoint definition tells exactly what elements and relationships are allowed within the view, so our tool could find those within the model and generate a view from the viewpoint definition.
As your models become well developed benefits start to come from automatically derived relationships. Not every relationship we use is created by hand. You can find more information on them in the Archimate Manual
Summing It Up
As your model grows the value we can gain from it also grows. For a model to realize its full potential requires architects to actually use it, have competency around it and have a level of discipline. When we achieve that modelling can be used to save time in understanding your enterprise and understanding the impact of change across the different IT aspects. At this point it can become an invaluable tool for management.