If we are changing something in our organisation, then there are seven simple questions that we have to answer.

What is the problem we are going to solve?
For whom are we solving this problem?
What do the solution look like?
What kind impact will the solution have for others?
When will the new solution be ready?
What are the benefits and the cost?
Are there any associated risks with this change?

The first two questions are the basic foundation for an Enterprise Architecture assignment. Without an answer to why and for who is it impossible to make a valid suggestion for something new. We should also be beware of the difference between the symptom and the cause so we ordinate the right solution.

For the other five questions could an enterprise architecture give parts of the answer, but not all answers. So if the solution includes change to business processes and IT, then it's time to call for an Enterprise Architect and involve her in the transformation.

If the solution have impact for other stakeholders and the solution includes business processes and/or IT, then it's also time to look-up Enterprise Architect in the phone book. The stakeholders could for example be other business units or customers that are impacted by the solution.

Few things in life are free, and changes to IT are not usually in this category. If it isn't free, then we also need the benefits so we can calculate the business value.

Timing is everything. When must we be ready with the new solution? The time perspective also sets a level for ambition. Can we be ready in time?

Finally is there the question what can go wrong. Without a risk assessment it's like to jump into the dark water without knowing whats under the waterline. Very much could go wrong!

Quite simple, don't you agree?

Disruptive architecture