#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

Kicking Off or Evolving Your Enterprise Architecture (EA) practice.

23 08 2011


TOGAF 8 EA Certification

I’ve been holding off on answering this question (How do I start an EA Practice?) for a while which has been posed from a few of my contacts. So I thought I would share a few of my experiences…over the past 14 years of being involved in architecture teams.

Top 3 realities:

  1. Architecture teams come and go depending on the Corporate/IT leadership…So hang on 🙂
  2. It typically takes years to mature an internal holistic EA practice
  3. With a little value, leadership will give you more responsibility (and rope)

Starting an EA Practice is a very difficult question to answer and is different for each organization. The consulting answer is “It depends”… There is no silver bullet straight out of the gate. There are only guidelines to follow and generally takes many years to mature an EA practice. With this in mind, focus on the priorities and value propositions from your sponsors’ and leaderships’ perspective. This will aid in keeping the EA momentum going so that you can continuously grow the practice.

Here are some steps to consider while strategizing an EA practice?

  1. Self Education: Understand what EA is…Self-educate, take a course, and/or recruit a reputable consultant.
  2. Be Prepared: Define your vision of EA which you can incorporate to future strategies, plans & executions.
  3. Probe for value: Ask questions and probe leaders of current pain points in your organization (IT/Business)
  4. Evaluate the Situation: Based on feedback, develop a business proposition, and communication for EA.
  5. Find and educate the Sponsor: Educate the need for EA to a potential sponsor (C-Level, VP, Director,…)
  6. Approval: Get approval to proceed otherwise go to step #1,2,3, or 4. If you don’t have leaderships blessing or a sponsor…Stop & re-evaluate.
  7. Evaluate current EA: Objectively evaluate the current state of your EA practice focusing on pain points
  8. EA Role: Clarify your role as Chief Enterprise Architect with your sponsor & leadership
  9. EA Leadership Team: Assemble an EA Governance Leadership Team (GLT) and its role
  10. Strategize EA: Collaboratively develop a 3-5 year strategy with the EA GLT and other stakeholders
  11. Prioritize: Prioritize the strategy into yearly executable portions
  12. EA Working Team: Assemble an EA Working Committee and its role (Domain Specialists)
  13. Plan EA: Develop an EA Project plan and schedule for the first executable portion
    1. Include determining a suitable framework and standards to get started
    2. Review the Plan: Review the EA Plan with the EA GLT
    3. Execute & deliver on your promises
    4. Go to Step #5

These are extremely high level steps to start an EA practice and not necessarily true for your organization, however, assuming you have prioritized value-added scope your delivery will gain the momentum required to keep architecture a value add team in your organization.


Got the Patience to Run the EA Race?

8 07 2011

This is a testimony of a good friend who is a data architect. We were both invited to speak at the SAP Sapphire conference in 2011. The subject we were speaking on was the importance of data governance and EIM. As we began to pull our slide deck together he mentioned, “I have been trying to get data governance going since 2003 and I am finally getting some traction with the business and executive. That’s 8 years!”

As I listened to him I nodded and smiled. I got up and drew a diagram on the whiteboard and replied “Is this what you mean? Because this is something you drew on the whiteboard in 1998. That was 13 years ago! That makes you a really old data architect.”

This is an example of the patience he showed over 13 years. How did he do this?

As I watched him over those 13 plus years there was something special about him we can all learn from.
1. The passion and love of your work
2. Never give up. Stand firm if it’s the right thing to do.
3. Always be intentional to improve and promote your idea whenever the opportunity arises.
4. Be objective, don’t worry if you don’t get your way. If the right people can not see the importance and value in the message then the business aren’t ready anyway.

His patience has finally paid off as key executives are bought into the idea and are undertaking a Business Transformation program in which data governance and data management are key components.

Endurance and patience is always important if you want to run the EA race.

The Software Licensing Challenge

23 03 2011

As enterprise architects we are always drawn into licensing agreements in some capacity. Having been involved in many licensing agreements there are some key things to keep in mind.

1. When re-licensing get a list of what you own, type of and capacity license, and how new products map to any new product licensing. This is a simple gap analysis to understand what you have and what is being proposed. Re-branding products can make this complex.
2. Wait to sign agreements until the end of a quarter or better yet, the year. Of course depending on the economy.
3. If you really need the software, try to get services included with the software prior to signing the agreement. Identify the competency level of the consultants; no change in support % rates; support incl. in first couple years,…
4. Be sure to do a proper assessment to choose the right SW product.

Need guidance in negotiating licensing?

Book Review: Zoom Factor for the Enterprise Architect

18 02 2011

Key Learning’s from Sharon Evans Book, Zoom Factor for the Enterprise Architect

Zoom Factor – Executive Summary

Just read a great EA book (a couple of times) by Sharon Evans called Zoom Factor giving her perspective on developing a high performing Enterprise Architect and the EA practice. It was one of those books you don’t have to force yourself to read. Sharon has given order to developing Enterprise Architecture skills through her experiences. Something which could be very chaotic if you did not have the appropriate guidance and/or mentoring. She does not attempt to solve every problem in this book. Instead, she simply presents alternatives and recommendations to develop an EA practice and career referencing numerous methodologies, frameworks, approaches, processes, and models, for the reader to research on their own – A great approach. The content is overwhelming and having to summarize each section has been a challenge. Depending on your EA experience you will get really good nuggets from the book or it will be completely transformational.

Section I Summary (Your Foundation)

In this section I could really relate with Sharons’ perspective and the importance to understand the basic skills required for Enterprise Architecture – The Five Steps to EA Excellence. The concept is growing basic architecture skills as you work your way up the ranks, through various opportunities and positions reaching different milestones in your career. I think back at my experience where it was difficult to plan a career as an Enterprise Architect since the role did not exist. That is not the case today and one can be intentional about “Growing up to be an EA”. Sharon articulates the basic skills and traits to develop oneself as an Architect as well as taking what is known or learned from previous experiences and applying it forward into the EA role in general – a simple yet effective approach. Finally she dedicates time to focus on the problem analysis process to effectively land on a best solution.  A skill every architect requires.

Section II Summary (Success through Process)

I call this section the meat and potatoes section. Here you will find a ton of content and reference material to consume which is sure to generate many thought provoking ideas. The section encompasses the architecture process, creating and presenting models, abstract and conceptual thinking, frameworks and creating blueprints and roadmaps.

She starts off emphasizing the need to be a slide maker and a white board drawer, being able to draw and present architectures to various audiences – From the Shop Floor to the Top Floor (executives). Using these skills effectively to communicate the architecture and aiding in the decision making process. Step out of your comfort zone to continuously develop these presentation skills, being able to take complex architectures and make them simple, easy for others to understand. Years ago, one of my bosses actually put a line item in my performance review to formally present 7 times per year to motivate my development. Set stretch goals and aim to achieve them as experience only comes with practice.

The 5 most common architecture processes and approaches are described in detail. Then she finally cuts to the chase and suggests embracing the core elements of the Zachmann and TOGAF frameworks to get started, and concludes how to move forward using a Basic Architecture Process and Principles. I am partial with her approach which knowledge and experience dictates to obtain fast results (Zoom In). The practice will always evolve going forward, but it is always important to show initial value. Later there is an entire chapter concentrated on the different frameworks specifically, and how to choose the right one for your organization.

What is architecture without developing models? Sharon compares models to artwork which is integral in describing problems and providing simple yet effective communication. Answering questions like Why, When, What, How much, and model structure is as well as “giving it that engineering style” to make the models robust. As in many other different architecture related approaches, books, and frameworks, the models are described. It would be awesome to have an example of all the required core models that need to be embraced. Wish I had this book to help several years ago; it would have streamlined the “School of Hard Knocks” approach we embraced. Also, check out the Zoom In and Zoom Out sections at the end of the chapter to find checklists on the bare minimum models list, and models to avoid respectively.

Having the ability to think abstractive and conceptually while in the weeds (detail) is a critical EA competence which Sharon calls the Zoooooom Factor. She explains the need to have the ability to focus on a specific architecture/problem, while considering the conceptual perspective. Architects need to have the ability to be able to identify the different types of patterns emerging from the architecture, solutions in the parts and as the whole, different views, its relation to change, the benefits, and challenges that might be encountered. In closing she gives some great tips and techniques to deliberately strengthen your skills. Some sound advice to help all architects be more effective.

Do you know the difference between blueprinting and a roadmap? If not Sharon brings clarity to what might be a little confusing to some. Covering the different types of planning architects are engaged in and depending on your current role will determine which one you will develop or participate in. There is an overview of each of the architecture deliverables, the different types, their scope, purpose, and benefits to aid the growing solution and enterprise architects. This is a great primer giving all a lot to consider.

Section III Summary (Soft Skills)

OK now it’s all about you, the EA and your soft skills. What sort of soft skills are important to develop as an enterprise architect? You find many of the answers outlined in this section? The following diagram effectively outlines the skills developed from starting as a domain architect to that of the enterprise/chief architect role.

The illustration and comparisons of the different types of architects are explained including the domain, project, and enterprise architects to help assess where you are in the EA journey. This helps outline gaps in soft skills we need to develop. Leading, politics, and consulting skills get their own chapter in this section to provide the detail required to help EA’s build their competencies. I’ll be the first to say there is some valuable content and a lot good reading in these chapters, even with my leadership and strategic planning experience. As for politics, can one ever learn enough?

Leading: Gain some great tips and ideas to consider when leading and mentoring your EA team. Sharon shares what to consider about to communicating your vision, preparing your executive communication pitch, and the many barriers EAs will face. (Use Cases Included).

Politics: Developing the skill to manage politics through influence, being resilient to criticism, building and nurturing internal and external relationships. But it doesn’t stop there, because in the “Zoom Out” there are some great political scenarios to avoid. Great stuff!

Consulting: Covers all the characteristics a good consultant needs to have to act as trusted advisor, facilitator, and overall great communicator. She breaks down each one of these topics to discuss the traits for each role and key advice on how to use them from an EA perspective. Towards the end the deliverables (Specifications, Reviews, Impact Analysis, EA Planning, Decision making, and the Toolkit) of the EA are described with advice on communicating the deliverables and abstracting the message to executive and upper level management.

As architects we all want to make diligent decisions and for those who have been there, done that, we know how difficult it is to make enterprise perspective decisions. Outlined are the aspects of making a great decision including some industry techniques, politics, prioritization, risks, trade-offs, instinct, and things to avoid. Following up on the decision making process are some tips on documenting the results and developing a good whiteboard scenario.

Section IV Summary (Vision & Big Picture Thinking)

I definitely enjoyed this read, in detail, of what it takes to have EA vision and Big Picture thinking. Embracing the importance of humility and collaborative natures to compile and understand other perspectives – how to put yourself in others’ shoes, both internally and externally. The need to understand the Business, Portfolio Management, and IT Architecture perspectives, while keeping your eye on the value EA brings to the table, and the risk associated for each of these perspectives. Being Enterprise Architects, it reveals how much architecture is not about us and our careers, but the ability to listen to others, the different perspectives, the aspect of governance, and doing what is right. Sharon concludes by providing a balance of foresight and questions to understand the other perspectives. Giving advice of where to look for gaps in business or system capabilities to drive efficiencies and innovation.

Are you a big picture thinker, or wanna be? Are you super busy all the time? Do you take time to reflect and organize your thoughts to develop collaborative perspectives into a supported vision and target state? Choosing to take time to analyze the whole landscape, evaluating and prioritizing stakeholder goals, missions, values, and concerns as a shareholder advocate is key. Always put the business before technology when developing the vision is Sharon’s message. Also of importance is that the EA is the change agent to communicate a passionate, compelling vision to build management commitment and support for the architecture, financial, and moral realizations. Additionally there is good advice on developing skills to prioritize your priorities, identifying value in opportunities, and driving value through innovation. Learn how to right size and align your architecture from the big picture perspective to ensure the vision is being realized through the portfolios, projects and architecture.

In probably the largest chapter learn what it takes to build an EA dream team incorporating great advice and questions to find the talent you need, team structure alternatives, motivating and mentoring the team, planning the workload, and generating high performance to continuously grow your teams EA and leadership skills. I have definitely not given this chapter the justice it deserves, so you’re just going to have to trust me when I say this chapter every EA needs to read.

Section V Summary (Achieving Architecture Altitude)

As architects we all desire to attain the goal of developing strategic plans which are aligned and supported between IT and the business. Your role as an Enterprise Architecture is to continuously develop the knowledge to assemble strategies, understand the business strategies and how they drive the enterprise architecture strategy, and value-centered thinking.

Need a strategic planning 101? You’ll find the most elementary steps in strategic planning from the business, IT, and enterprise architecture perspectives, their basic components and how they overlap. What to do if you can’t find a documented business strategy (That never happens), tools to help perform your analysis, assessment, and how to develop your Enterprise Architecture Strategy.

To be the business-savvy architect who is genuinely interested in creating value for your organization, is a statement I truly believe is a key success factor in developing your role as an EA. Sharon shares advice to build your entrepreneurial spirit to be sensitive to current business issues, market forces, leading change, and overcoming the fear in failing. And as read on you’ll see how quality and your integrity count in building your career.

Most architects I have chatted with always ask the question “How do I measure the value and maturity of EA?” Well, you’re in luck, because Sharon shares 10-15 pages on measuring EA, the returns, and methods to communicate the results to your stakeholders. This includes initiating governance committees, roles and responsibilities, and how to run effective governance groups. This will ultimately aid in setting priorities and doing what is right.

Finally, Sharon describes the role the EA has as the mechanism for change. Understanding the seven levels of change, how change works, and how to get others to embrace change a little easier. How controlling change can only occur when you know what you have, what you need, when you’ll need it, and who will implement and manage it. This is explained in some depth and provides advice to consider in mitigating the fear in change.

Zoom Factor Closing Review

Overall this book is definitely worth the read for all those currently in the midst of architecture no matter your level of experience. For those of you who are just starting out a career as an Enterprise Architect, this book will be a key reference guide for you going forward along with your relationships other EA’s, forums and groups. Even if you already are a high performing EA, certain statements and chapters will leave an impression on you. They will prompt you to continuously incorporate them into your career so that you can be all that you can be.

Kindle Version of Zoom Factorhttp://amzn.to/eosoYw

Best Regards,

Darin Paton

Cornerstone Consulting Inc.


E: dpaton@cornerstone-ea.com

W: http://www.cornerstone-ea.com

M: +1 403.472.7744

%d bloggers like this: