Sunday, March 19, 2017

How to sort out the Business Problem - When, Where and Why

This post is part two on how to sort out a business problem using the tools of an investigative reporter.   My first post examined the Who and the What. Today's post examines the When, Where and Why.

When did the problem start?

It is helpful to gain an appreciation of the depth of a business problem by probing and exploring its past. By researching a problem to find its origin, you can learn a lot about the organization and business practices that surround a problem.  I will have to say that I am biased in this approach. I tend to be a history buff.  So, I lean towards investing some time and effort to gather whatever background information is available.

To gather some history about the problem you can start with a conversation about what the problem looks like today, then explore what the problem looked like at different points in time (6 months ago, 2 years ago, maybe even a decade ago). Try to see if the problem has evolved over time.  Why is this important?  A problem that is systemic and pervasive usually has not been solved for a reason.  You need to flush out that reason. Perhaps the approach taken or technology selected was immature, not well aligned, or maybe the wrong platform was chosen.  In my experience, re-introducing a solution approach that was tried and failed in the past will not be readily or eagerly accepted. Therefore, for no other reason, try to gather information about a problem's history in order to avoid repeating mistakes from the past.

So, what if you determine that a problem has only recently erupted?  This type of situation takes you down a couple of possible paths. Perhaps the business just wants to get back to where things were before the problem occurred (an original business state).  Your focus then is on removing the process or technology that is the cause of the problem and replace it with a solution that brings the business back to their original state. Sometimes that may not be possible especially if the original technology is no longer supported or the original process is no longer a fit for the organization.

Generally, I tend to view a problem situation as an opportunity to generate a vision for a new and improved business state.  Sometimes, a small change or improvement to the current technology or processes in place, can alleviate the problem and move the business to a new and steady state.  To be honest, it is not always easy to do.  Sometimes architects prefer to "rip and replace" and move the business to a platform and process that they themselves are more comfortable with or knowledgeable about.  That can be expensive, so unless the current platform or process is fundamentally flawed, I try to work with what is there and see if I can make it better.  

So, where does the problem exist?

As I pondered how to introduce this section, I envisioned a large double edged sword.  An important question that should be asked is; Where else has this problem occurred and does this problem currently exist in other parts of the business? Now for the sword.  Asking this question is opening a can of worms for solution architects.  You have inadvertently opened the door and entered the room for Enterprise Architects.  Why is this a problem?  Attempting to solve enterprise wide problems on a fixed and limited project budget is a recipe for frustration and disappointment.

The reason you should ask the Where question is not to solve the enterprise problem. Rather your goal is to find a solution for your business area that is flexible enough or can be built upon so that one day it may be used by another solution architect for another part of the business.  Enterprise problems are hard to solve, and typically require more resources than are available for a single project.

The Why question

We have discussed the when and where, now to tackle the why.  When looking at a problem you should consider the following question - "Why is this particular problem important to solve today?"  This is a tough question to ask. Rooted in the question is a basic assumption that at any point in time, there are multiple problems to be solved within the business, so this becomes a discussion around business priorities.  It is typical that different parts of the business will have different priorities. If the business outcome you hope to achieve affects multiple parts of the business, then you should be ready to deal with competing priorities. So, what is your task?  Capture the priorities that may be competing (either for time or for resources) with the problem you are being asked to tackle. Bring it to the attention of decision makers around you. Your job is providing the information that they need to decide on which priority gets worked on first.  Respect their decision and do your best to deliver on what has been deemed as the highest priority problem.

In Summary

To summarize, you should be prepared to explore the past when researching a business problem.  You may find out that a problem exists in multiple business areas.  Do not attempt to solve an enterprise problem on a limited project budget.  However, you should try to come up with a solution plan that is flexible enough to be used by other architects for other parts of the business. Finally, determine where the problem you've been assigned is ranked in the larger scope of business priorities.

I hope you enjoyed this article.  Future posts will delve into how to take the information you've gathered and use it to initiate a comprehensive solution design.


Saturday, February 25, 2017

How to sort out the Business Problem - Who and What

The most important step you take when you embark on a solutioning exercise is to clearly define, describe and sort out the business problem you are tackling.  Sounds easy right?  You would be surprised how many solution architects immediately jump to the preferred technology for the solution and misinterpret or completely ignore the business problem at hand.

So what are some steps to take when defining the business problem?

Think of each business problem as a case to be solved.  Before you leap to your final conclusion (and solution), make sure you have gathered some facts about the case.  Some of these fact finding techniques include using the five W's similar to investigative reporters (Who, What, When, Where, and Why)

In this post, I am going to focus on the Who and the What for getting to the root of a business problem.  So step #1 is:

Identify the Who and be specific

Identify who in the business is specifically making a request.  Again this sounds easy but how many of us have been faced with the following request..."The business would like a way to allow customers to easily access information at any time of the day."

Start by asking a simple question... provide me the specific names of who in the business is asking for " the simple access method".  Is it Jake in accounting, Stephanie in engineering, or Deepal in customer sales?  Asking for who by name starts to narrow down which part of the business (sales, accounting, marketing, engineering) is making the request. Next question is who are the customers, and ask for specific examples. Are these new customers, returning customers, or prospective customers? Keep asking for clarification and make notes of who is going to be served by the solution, who is going to benefit from the solution and who is going to be impacted by it (either directly or indirectly).

The big red flag - If you start asking for the who(s) and are getting vague answers or non-answers then you may be facing the "hypothetical business problem".  This happens more than we would expect where someone (usually in IT) is concerned that a problem may be occurring in the business, but has no specific examples of stakeholders so describes the problem in general and generic terms.

Identify the core and central What

What is the single biggest problem that you are trying to solve?  If you end up with a half a dozen whats...that is a big red flag, you are attempting to solve too many problems in one solution.

A great question to ask (and I am amazed at how many times it is never asked) is what is the expected outcome for the business from the solution.  If the response comes back quickly and clearly, then you are on your way.  You can come up with a solution option (or options) that are measured by how far or how close each option comes to the reaching the desired business outcome.  If however the outcome is not clear or cannot be articulated, then keep searching for what is the real problem you are trying to solve.  Sometimes people see a problem and want it to be fixed, but really aren't sure what "fixed" is going to look like.  In this situation you will likely spend countless hours and dollars to end up with a non-satisfactory solution as there is no real measure of what satisfactory looks like.

So important tip #1 - Every business problem should be identified in terms of a What, have named stakeholders and benefactors (the Whos), and be agreed to by yourself and your business team (if you cannot agree on the problem, you won't agree on the solution). The solution should be marked and measured in terms of a clearly defined and agreed to business outcome.  If you are seeing multiple problems, lack of a clear benefactor, and have no clear agreement on the outcome, you need to keep investigating your case.

Some things to watch for when sorting out a business problem:

- Has the business person (or persons) made similar requests to other solution architects (I refer to this as shotgunning business requests...sending out the same request to as many SA's as possible and hoping that someone will figure out a solution.  Find out who is actively working on the problem (maybe you are going to duplicate the effort of someone already assigned).
- Have others tried to solve this problem in the past? If so, why does the problem still exist? If other attempts have failed in the past, you want to ensure you attack the problem with a different approach or you will end up with the same result.
- How many users in the business will benefit from solving this particular problem?  This is a tricky one.  People tend to feel that their problems should be solved at any cost, and as SA's we try to accommodate but in tough economic times or tight budgets sometimes we have to factor the benefits of a solution to the business as a whole and not to the individual.

I hope you find these tips useful. In my next post, I will tackle the three remaining W's; the When, the Where and the Why.

Saturday, February 4, 2017

Starting the Blog (Again)

I just wanted to share what inspired me to start up a blog (again) on Solution Architecture.  I was interviewing a candidate recently for a Solution Architect position and he casually mentioned that he had read my blog.  My initial response was "that's amazing .. nobody reads my blog". To be truthful I had forgotten that I had started a blog a few years back.

So I decided to search for "solution architecture blog".  Sadly, my blog shows up as number seven on the results list even though I hadn't posted anything for 3 years.  This clearly highlights that there is ample space for me to opine about the profession.

With that in mind, I am working on a resource page for Solution Architects.  I intend to provide links to other architecture bloggers, technical publications and articles that catch my interest.  So stay tuned for that.

Mostly though, I am going to try and share my own thoughts and experience on what makes us good Architects.  If your interest is Solution Architecture, hopefully you find this site useful.


Solution Architects should learn how to talk SMAC - Part 2

The following is a post I started in 2014 and never finished.  I've decided to post it "as is" to show where I was when I stopped blogging three years ago.

This is part 2 of a series that discusses the importance of understanding SMAC - Social Media, Mobile, Analytics and the Cloud.  In part 1, I blogged about the importance of Social Media and Mobile.  In part 2, I will look deeper into the areas of Analytics and the Cloud.

Analytics and Big Data

Analytics is the ability to capture information that is most important to the corporation, your customers,  and your products or services that you provide.  It includes the technology required for storing it, analyzing it, and provide reports and dashboards for your stakeholders so decisions can be made based on accurate, up to date information.

Analytics is nothing new for IT.  What is changing analytics (both the technology and the methods) is the emerging trend to want to analyze "Big Data".

So what makes big data ...Big?  Those who have worked in Point of Sale (think big chains like Walmart and Target) have been dealing with "big data sets" for decades.  Telecommunication companies that have to rate and bill cellular calls are familiar with "big data sets".  So what's changing.

Let's look at the point-of-sale scenario.  People make the majority of purchases at given times of the week (Saturday and Sunday) and certain times of the year (Black Friday in the US, Boxing Day in  Canada) and the number of shoppers is growing but not at an exponential rate (The rate of point-of-sale growth should be roughly equivalent to population growth).

The change that is coming from a data perspective is another emerging trend, the "internet of things".  The internet of things are smart devices that are connected to a network and can transmit data at intervals that is measured in seconds or sub seconds.  And unlike shoppers that have to go home eventually and pack all their purchases away, the smart device can transmit data 24 hours a day, 7 days a week, 365 1/4 days per year without pause.

In a recent report, Gartner describe the data that will be coming as real time readings of temperature, humidity, motion, vibration, facial expression, voice inflection, vital signs, etc.

Here is a scenario to think about.  At a sporting event, game sponsors want to measure how often their particular banner or logo is viewed by a fan and more importantly which fans (male, female, young, old) are attracted to the ad.  The fans are equipped with a "computerized eyeglass" device so every movement of their eye is tracked throughout the game.  By combining eye tracking movements with fan demographics, seat location,  the temperature and time of the game (day or night game) over a series of months, sponsors can determine if a game sponsors products and banners are more appealing to a certain demographic seated in certain sections of the stadium in the heat of July or the cold weather in November.

So for the Solution Architect, it becomes an exercise in understanding the capture device (the eyeglass), the sporting event, combining that with a multitude of data sources (date, time, temperature, location, plus individual demographics) and then tying it back to product or service data to measure positive or negative impacts to sales.

Now multiply this scenario by the thousands of sporting events around the globe (soccer, football, cricket, baseball, basketball, and hockey) and you can see the "explosion" of data for this one specific use case.

The Cloud

This section was never completed.  It is fascinating how the cloud has evolved over the last three years.  I will endeavour to share my current thoughts on cloud technology in future blog posts.


Saturday, February 22, 2014

Solution Architects should learn how to talk SMAC - Part 1

There are some acronyms which just make you smile.  For those that are not familiar with "SMAC" it is the acronym referring to Social Media, Mobile, Analytics and the Cloud.  These are four key areas in today's IT space that Solution Architects need to study, learn and understand.

Let's start with Social Media.  It is now firmly in the consumer mainstream as most of us are using Facebook, Twitter, Instagram or some other social media app.  What interests Solution Architects with social media is the integration of social media products with traditional Enterprise applications.  Instant message products such as Jabber and Lync have been around for several years and IM'ing at work is pretty popular. 

What I am seeing is the emergence of apps such as Yammer and Jam that provide a "Facebook look and feel" within a corporate environment.  At the company I work at, we have recently rolled out Yammer corporate wide.  As the head of our Architecture Practice, I am "all in" with this tool and will blog about the challenges and benefits of using it over the coming months.

I believe that these types of apps are still in their infancy in the corporate IT world.  A lot of corporate dialog, particularly in traditional IT circles is still captured in email.  But as newer workers enter the corporate world, I expect to see more and more "email conversations"  transitioning across to social media tools.  Evolution is inevitable.

Mobile Apps

If you are in an IT organization today, you will likely have been engaged in one or multiple projects which involve the rapidly expanding world of mobile apps.  In short, this is emerging as the application platform of "now" and is the launch pad for new ideas and new products by a number of vendors we work with.  Smart phones and Ipads now outnumber desktops and the growth curve continues.

I did some research and found a 20 minute video produced by Gartner a few years ago that describes the challenges faced when delivering a mobile architecture.  Even though some of the products identified are now dated, the fundamental problems that we must work through are as relevant now as they were two or three years ago.  If you have just been tagged in your organization as the "Mobile Architect", watch the video and this should get you on your way.

Here is one more plug.  I currently follow a blog by Kevin Benedict from whom I shamelessly borrowed the term "SMAC".  His blog is a must read for anyone that wants to get a leg up on mobile and other trends.

So that is end of "Part 1".  For my next post, I will blog on Analytics and the Cloud.  One of my colleagues, Ivan Chen who sits on my practice council recently delivered a great presentation on business intelligence technology, so will share some of those findings in my next post.

Sunday, January 12, 2014

So you want to be a Solution Architect?

If you are reading this blog, you are likely a Solution Architect or you are contemplating a career in Solution Architecture.

Welcome to one of the fastest growing, and probably least understood careers in IT.

First a little about myself.  I started my career in IT in 1989.  Back then we were programmers and system analysts.  Along the way we became data analysts, technical systems analysts, software engineers, software architects, technical business analysts, business systems analysts....you get the idea!

So when did we become (or want to become) Solution Architects?  The role has evolved as systems have become more complicated, more integrated and with more components than the systems of the past.

So what are the core skills to become a good Solution Architect?  The core skills you will need to become a Solution Architect are:

Knowledge of multiple technology platforms

As a Solution Architect, you will be challenged with having to construct solutions using a mix of legacy software application, newly purchased vendor applications, “to be determined” custom applications and of course the new kid on the block - Software as a Service (SaaS) applications running somewhere in the cloud.  For each of the component systems, you will need to know the strengths and weaknesses of the vendor product, the preferred platform to run on and a host of constraints and dependencies that can make or break your solution design.

Knowledge of an Enterprise Architecture framework

There are many different Enterprise Architecture frameworks for you to learn, and to be an effective Solution Architect you should be fluent in at least one them! In the Architecture Practice that I lead, we become certified on the TOGAF framework (current version is 9.1).  TOGAF has been around for a good number of years now, has a loyal following and provides the essential knowledge and guidance on building a good architecture.

Strong communication skills

A Solution Architect can have a solid design and deep knowledge but if he or she cannot communicate effectively to an audience the design is much less likely to be realized.  Documents and diagrams do not speak for themselves.  Think about a great presentation you've attended where the speaker had everyone in the room hanging on every word.  Now go back through the slides and read them to yourself.  Does the message in the captions capture you?  Are you as engaged or engaged reading the slide pages to yourself?

Great negotiation skills

In some cases no matter how much time and effort go into your designs there are doubters and skeptics.  No matter how well thought out your solution is, someone in the room is going to challenge it.  You need to get to the root of an individual's concern.  One of my favourite questions during a design review, where I am meeting a huge amount of resistance is to ask  "So what is your chief concern?".  Once you have determined that you can follow with "So here are the options we have".  After you have laid out the options, a good response can be "So for this reason, the solution I have chosen is".  After you have justified your design, the next question should be "Do you have any other concerns?"...

So what is your experience?  What are some of your favourite negotiating techniques?