Using TELOS For Validation & Feasibility Checking

TELOS is one of those handy acronyms we use for validation and checking we haven’t missed anything in architecture. This blog introduces TELOS.

I use TELOS quite a lot when reviewing architecture. One of the reasons why an architecture review with teammates often looks different is because when we ask questions on architecture what tends to happen is some of our lead architects run through TELOS in their heads – and focus in on areas where things need a little bit of attention.

We use it whenever we are looking at investment proposals, or we are presented with architectures or any kind of feasibility study.

Breaking it down.

TELOS is short for:

Some of the questions we ask can technically belong to several areas – such as a question “have you considered software licences for the servers?”. It doesn’t matter if the question is asked as a Technical question or a Economic one – the important thing is that questions are asked. Lets explore this this one part at a time.


This is things relating to technology. it can include things such as technical requirements, skills, capacity and other things relating to the fitness of the technical solution.

Some typical technical related questions:

  • Do we have the required software?
  • Do we have all the required hardware?
  • Are we reusing existing technology/competency wherever possible?
  • Do we have the skills we need to use the technology or will we need to train or get skills in?
  • Will we need external collaborations/have third party dependencies?
  • Will the solution defined meet initial performance expectations?
  • Will the solution defined meet mid term usage / functionality expectations?

Ive found in the past that its typical to not fully consider your skilling and training costs. I also think that capacity planning is also an area that often requires attention. Many times i have seen a positive problem occur, where a platform is implemented, costs and a return of investment are declared but the actual platform doesnt have the capacity to provide returns that are promised.

Its also important to think lifecycle of the solution and all its components. We need to have an understanding of how long technologies will stay relievent. For example if a software product we are using is several years old and a vendor is known for releasing new things every 2-3 years, will the solution realise its goals before we need to make further changes and incur more costs?


Relates to economy and includes such things as profitability, revenue tarkets and break even points.

Some typical questions might include:

  • Are all the costs defined?
  • Are all the revenue streams defined?
  • Have efforts been made to provide the most economic design?
  • Will there be an adequate return of investment?
  • How long will it take to show a profit?
  • How expensive is the solution? is it too expensive?
  • Is our pricing competitive?
  • What is the costs of any potential risks we see?

There are lots of mechanisms out there that can be used to help model and design a proper business case. As a minimum when looking at investment proposals I like to see a Business Model Canvas defined, because you can quite clearly see both costs and revenue streams. Of course not all architecture has a goal to provide financial value.

When looking at a promised return of investment we are looking for the reasons that justify things. Its not enough to say a product will return a million euros in the first year – we need to understand why – which raises further economy related questions

  • How big is your target audience?
  • What is the potential revenue for us of everything in the sales pipeline?
  • How often do we win these sales cases?


Describes things relating to legal.This can include ensuring we adhere to local law, EU Law, or any industry regulation, or contractual obligations.

Typical questions might include:

  • Are we complying to EU laws?
  • Have we ensured we are following all the ISO standards and met other commitments we have promised our customers?
  • Have we considered any industry specific legal requirements?

Some requirements are obvious – such as GDPR because it has such extreme implications and gets a lot of publicity. Other legal requirements are not so obvious. For example we may need to retain financial records for a fix length of time. Its important to ask the different stakeholder of an architecture about any potential legal requirements, so they are not missed.


Relates to things such process definitions, operational needs, lifecycle and change management

Some typical questions might include

  • Are all of the actors properly defined?
  • What kind of resources or teams in the organisation will be required?
  • Will we need to reorganize processes or teams?
  • Will we need new resources?
  • Have we made agreements with operations to implement our solution?
  • Will there be costs in training?
  • Do we have proper KPIs or automation in place?
  • Will new teams have to be established?
  • Will there be staff resistance to the change?

We talked about costs of training and skilling within Technology, but it doesn’t stop there. If we implement a new system or new processes / ways of working we need to ensure people are aware of them. There could also be formally required training, and needs for the building of a communication plan.

We also need to have mechanisms in place to monitor health of our operations so we can adjust our designs as we need to.

Proper architecture design really helps here. Resistance to change should also be planned for because sometimes one negative person can derail an entire project.


Things relating to resourcing such as timescales, road maps and resource availability planning.

Things relating to resourcing such as timescales, road maps and resource availability planning.

Some typical questions relating to this might be:

  • Given our current expertise are the timescales realistic?
  • Will the project be too resource intensive?
  • Will there be availability issues for key competencies?
  • Are there any timescale pressures that need to be met?
  • Will the solution be built in time to realize its benefits?

We need to be realistic with our timescales, and resource availability has major impacts on this. If resources are not available a plan should re revised because even with the best intentions you will fail. Time commitment for a percentage of time on a project should be time-boxed. if we have one day a week for a project we need to ensure all resources are available on the same day as part of that commitment, or projects will just drag on.

Key milestones or dates should be defined for things such as launches, and sometimes there are business impacts for being late that need to be understood. For example, when technologies are new the opportunity to sell them might be greater at the technology release than a year later.

A plan or road map should exist to ensure that the project / architecture is delivered at the cadence that is needed.

Summing It Up…

Its quite possible that going through this blog you come up with other questions that would need to be answered in a TELOS assessment, and the questions I have presented in this blog are not intended to be comprehensive so much as a starting point for people who want to start to use TELOS in their working practices.

The questions that I have asked in this blog do not necessarily get answered in a single document – although you might chose to have a TELOS section in a high level design. The questions can be answered in many places in our architecture. A road map view might exist to cover scheduling. A Business Model Canvas may cover most of the concerns we have in economy. Its possible we may cover everything in the requirements documentation or with use cases. Sometimes I have built TELOS into requirements templates, and sometimes I have built TELOS assessment templates. Sometimes its enough to just talk it through in conversation.

Knowing TELOS improves our ability to see potential risks or holes in architecture before they happen