#016 Make your Technology Assessment More Objective and Structured

28 11 2012

Over the years as an enterprise and solution architect I have been involved in many projects to find the best technology for a business problem.  In most instances I have found that either IT or the business already have a solution in mind. However, typically after gathering the functional and non-functional requirements, the solution is not the right fit for various reasons. This is why having the  technology assessment processes and templates in your architecture toolkit are so important.

So I thought this would be a great article to share with other fellow architects out there that are requiring a process to assess and evaluate solutions for the business. Here are my 16 steps which you can trim down depending on the circumstances:

      1. Kick off the assessment. If you’re thrown into a project where an assessment is required then respectfully provide a justification to do one.  The number one justification I like to use is it protects the stakeholders and company from selecting the wrong or rigid solution due to 1) Lack of requirements or 2)Lack of Governance; 3) Stakeholder involvement.  It’s all about doing what is right which most people embrace.
      2. Business Strategy and Roadmap Workshop.  I like to kick off the assessment with a strategic planning session where the business gives a perspective of why the solution is required and how it fits into the long term strategy.  Most times the business can articulate this very clearly, however most of the time they are only trying to solve an isolated issue.  You will need to discern whether a strategic workshop is appropriate based on the culture, it can however, facilitate the bigger picture.
      3. Project Priorities Workshop.  Focus on solving the business problem and keep the workshop on track.  The business always has a lot of nice to haves, so it is your job to focus on the project goal.  I like to use the following quadrant diagram to find out where each priority lands.
      4. Functional & Non-Functional Requirements. Have some good Business Analysts help hammer out the requirements and coordinate the review.  Of course Architecture standards helps with the non-functional requirements – and make sure the architects and specialists are engaged.
      5. High level process inventory and documentation (AS-IS/TO-BE).  Keep the processes high level as there will be time during the detailed blueprinting to refine these processes.
      6. Define the Logical Application and Information Architecture. Develop the required architecture views based on the stakeholders.  A modeling tool is always good to have, since it can really streamlines your work.   I use Avolution Abacus, although I have used Aris, Aris Express, and of course Visio, but I find Abacus for its intuitiveness and flexibility.
      7. Choose vendors for product evaluation.  If there are no internal solutions you will need to find vendors and sometimes you can use research companies like Forrester, Gartner,… other times you will need to search the net, ask the business and technical specialists, and reach out to possible partners.   Try to find vendors that are familiar to the industry you’re in and obtain the magic quadrant and hype cycle documentation if available.
      8. Produce the vendor questionnaire.   Develop a questionnaire based on the logical architecture and requirements for the vendors but keep it simple.  Limit it to around 30-40 questions in total.
      9. Schedule vendors for demonstrations.  Make sure to have a vendor demonstration script based on your needs otherwise demos will get off track.  In some cases it requires putting together data sets to support the demonstration.
      10. Send out and review the vendor questionnaire.  Before you send out the questionnaire make sure to contact Supply Chain to embrace any internal procurement standards.  Have a deadline and single contact for questions.  Review the responses collaboratively and score.
      11. Conduct vendor demonstrations and validate key functionality. This allows your team  to ask questions not in the questionnaire.  Make sure key technical and functional decision makers are present to ask their important requirements. Also, get the stakeholder to score the demonstrations and take notes.
      12. Score vendor questionnaires & demonstrations.  Score collaboratively through a post-demo meeting and document the great feedback.  If scoring is close meet with stakeholders 1:1 for another feedback loop.  You may also have to put a weighting on important requirements.  For example, a question could be scored from 1-4, however if t has a weighting of 3, then the final scores could range from 3 to 12.
      13. Shortlist/select the vendor for a Proof-of-Concept.  You will typically find the governance team will have a favorite vendor which the scoring should align to.  I typically find the result is pretty cut and dry.
      14. Execute the Proof of Concept (PoC).  Keep it simple to begin with, doing just enough to do a PoC competently.  Make sure that Legal gives you recommendations of what is required of the vendor.  i.e. Confidentiality agreements, liability insurance.   Have defined decision gates  at certain points to ensure the technology is still a good fit.
      15. Complete the Technology Assessment & To-Be Architecture documentation.  During the PoC prepare a decision document of the physical architecture options and a recommendation.  Complete the technology assessment as much as possible until a final governed decision is made.
      16. Prepare the business case and implementation plan.  When the decision is final work with the PM to help put together the business case and implementation plans.  You can find my ROI template in the BOX Flash Widget on the right frame.

Multiple times in my career I have either had to execute a technology assessment or coach architects on how to perform the assessment to help the business solve their issues.  The process and templates have evolved over time working with various organizations and peers in the industry.  The best tip I can give you is get the stakeholders in a room regularly to review and give feedback on the process.

What sort of Technology Assessment Processes do you use?


Managing Project Architectural Challenges

7 01 2012

The original title was “Managing Projects Implementing Crap”… but I thought that was a little too harsh. It’s reality and each organization will need to make difficult decisions as part of each implementation.…

Occasionally significant architectural principles/standards of an EA Strategic
implementation, or related project, are sacrificed, even when architectural governance
is in place. Why? In this series of blogs we will look at:

  1. Some of the typical reasons and principles that are broken;
  2. Try to understand why the decisions are made; and
  3. How to manage and respond to the architectural issues that arise.

Some of the typical reasons and architecture principles that are violated

Having been part of many large enterprise projects since the early nineties I find that many
businesses executing on their strategy through IT related programs or projects end up making decisions that compromise key architectural principles. It begins during the project preparation phase
when an estimate is delivered. The typical large project estimating process follows a scheme similar to:

  • 10 days for a very complex (i.e. Process, Report, InterfaceConfiguration, Enhancement…);
  • 7 days for complex;
  • 5 days for medium complexity; and
  • 3 days for simple.

However, more often than not, the preparation and estimate seldom reflects the reality.  This ends up forcing the implementation teams, to make decisions that do not appropriately favour the architectural principles or standards.

The three significant architectural principles I typically see violated across all architectural domains (process, application, data, and technology) are:

  1. Lack of reusability – The solution will meet the immediate business requirement and scope of the project, however, when the solution needs to be extended it requires significant rework, if not a complete re-implementation.
  2. Solution is not operationally efficient – The requirement is implemented with many manual processes to support the end solution.
  3. Lack of Sponsorship and/or Requirements – I can’t tell you how many “Build and they will come” and “Technology Drives Change” projects I have been part of and the majority of these implementations rarely
    end up being successful. The technology ends up getting implemented, but the solution does not meet the business need and the business does not use the solution.

Now this does not mean there won’t be exceptions and a process in place to manage those architecture exceptions. I’m talking about architecture design/principles that are intentionally or unintentionally violated.

In one case, having presented the architectural documentation to a small group of enterprise
and solution architects they quickly realized there was no business engagement and all principles of a single architectural domain were violated.  This caused the project to step back and re-strategize its approach.

In another example, the developers for a solution were pressured to deliver on time rather than adhering to architectural reference models and design.  A quick internal project governance meeting was held to review the options and benefits to make a decision that was best suited to the company and stakeholders versus the project.  The developers were given more time to implement
the solution the correct way.

There are examples, when suitable options and recommendations are presented to the Project Governance
Council.  However, a decision is made to not embrace the recommendations made for various reasons. Sometimes the decision does not even make it to the governance council. In the next blog we will discuss why these issues arise and how to appropriately manage and respond as an enterprise/solution architect.

What are your experiences?

Streamline TOGAF with Enterprise Modeling

3 12 2011

Ever try to find the most current architecture model or documentation in your organization?

In the majority of organizations I’ve been in it has always been a challenge.

My modeling experience:

      1. 1997-1998 Modeled in Oracle Designer 2000 which at that time had pretty good modeling capabilities. However, was not a priority to the business to sponsor and lost traction.


      2. 1998-2007 Visio was the accepted tool of choice, probably since the tool is very intuitive, file based, and seemed easy to search… 🙂


    3. 2007-current Enterprise modeling tools have been my choice of tools lately, with the exception of some engagements where Visio still is.

Some Key Enterprise Modeling Functionality

      1. Allows you to centrally store and version your models.


      2. Each object (i.e. process, function, system, interface, data, infrastructure) has characteristics attached to further describe the object.


      3. The objects store metadata of what they are and do.


      4. Well defined drawings (views in TOGAF) define relationships between the different objects which allow for the generation of TOGAF core matrices and catalogues


      5. All objects are reusable including all the characteristics, descriptions/documentation, and relationships. (i.e. If you copy an object for your drawing, all other relationships are retained)


    6. For each model, documentation can be automatically produced defining all the components of the drawing

For more information on EA modeling tools check out this site.

What is the Value Proposition?

    1. Promotes an “Single Source of Truth” or the authoritative source for models and object definitions resulting in efficiencies in:

  • Streamlining business processes
  • Time saved searching for most current documentation

Value: Consultants $$$$, architects $$$, project staff $$, support staff $

    2. Accelerates modeling and documentation for projects since:

  • Models are centrally stored in the authoritative source.
  • Accelerates models as core matrix and catalogue deliverables are automatically generated.
  • Documentation can be partially automated as each object has the textual documentation associated to itself.

Value: Consultants $$$$, architects $$$, project staff $$, support staff $

    3. Allows for impact analysis to reduce risk in organization changes.

Value: Risk $$$$+


      1. Getting buy in from the executive to embrace the opportunity


      2. Keeping the information up to date and populating the enterprise modeling repository


      3. Managing change to deliver the information to the business and training


    4. Governance service to manage the submission of new and updated models

%d bloggers like this: