Tag: solutions

  • Ask And You Can Find The Tool

    Ask And You Can Find The Tool

    A recent discussion with an associate reminded me how often we ignore some great solutions for our problems. The Internet provides us with an easy way to evaluate literally dozens of options for many of our common problems. It is worth the investment to find the tool that suits our needs. Even better, we can learn that our problems are more common than we think. Even a niche problem will often have a number of potential solutions a good search away. While we can all stumble around and find some great gems, sometimes a plan is helpful.

    Avoid Distractions

    Apple showed that less can be more. Likewise, there is a lot of research related to having a large number of options. That makes sense. We can all relate to analysis paralysis, but it does occasionally sneak up anyway. A problem we want to be solved seems to make us even more susceptible to this problem. It creates a sort of “kind in a candy store” situation. We focus on a problem, find some solutions and suddenly we can be almost giddy. If you doubt it, then take a look at search results for any passion of yours. Maybe check out some new cars, beach homes, or enticing coffee flavors. When we get what we want we are more than happy to enjoy the shopping experience and getting lost in what-ifs. The Internet provides us too many options so we need to reduce that list quickly.

    Have A Plan

    One of the essential reasons for an RFP is to define what an organization needs. We see this in problem-solving all the time. A well-defined problem is easier to solve than one that is vague. Take similar steps to start your search to find the tool desired. Think about what you want and create a list of priority features along with some nice-to-haves. You can do this in a matter of minutes, and it does not need to be complete. Start your search focused on solutions that provide the requirements you listed. It is not uncommon to learn about features that most providers include or new options you did not know you required. Feel free to adjust your list as needed.

    Be Heartless In Reducing Options

    The final goal is to get your list to five options or less. That five number is on the outside. Most lists should be down to three at this point, if possible. That may seem like a difficult task. However, I have found in most situations you can find the products available and reduce the scope of “viable options” to a few within a few days at most. Also, it only takes days when there are dozens of options and they are complex solutions. Most applications whether a task tracking solution, an e-commerce platform, or a coding utility, can be swept through in a matter of hours. You can often find what you need to know with surface reviews and related searches. They will either meet your requirements or not. Price alone can often reduce your list quickly.

    Due Diligence

    The final step is to evaluate your shortlist of options. This step is time-consuming and essential in making the best decision. It often includes installing a trial version or using a demo period to get to see the solution in action. You might even watch vendor presentations and spend time discussing how a solution is the best for your needs. The process may seem like something that requires too much time. Nevertheless, spending time to find the tool or effective solution can often save you hours, days, or even months in the long run.

  • Getting Started With a Solution Architecture

    Getting Started With a Solution Architecture

    One of the first questions asked as I start or join a software project is what I think about the solution architecture. This question may either be an attempt to have the current architecture assessed or a first step in building the application. The answer can often be frustrating to the listener as it always begins with a question. Furthermore, there are questions that follow that first one. That does not mean there is no “template” for architecting a solution. However, I think it is important to look at what we are doing in order to take the proper steps.

    Define The Problem

    The most critical factor in creating a solution architecture is not the design of the architecture, it is the solution. Otherwise, you are setting up a classic cart-before-horse approach. There is just too much about a well-designed solution that hinges on the problem you are solving to not focus there first. I once heard it best described as a good architect keeps asking “and then what?” as they listen to someone walk through a problem. The first step is understanding the problem and related processes in detail so you can avoid designing yourself into a corner. A failure to properly understand this point counteracts the skills of even the best architects.

    Requirements and Constraints Drive Solution Architecture

    Everyone likes to start with an “it does everything” approach to define a solution. There is nothing wrong with this. However, a solution architecture that is the best fit requires us to drill deeper. Here are just a few key data points every modern solution needs to address.

    • Who is the Audience?
    • What is the size of the initial user base? (how many users?)
    • How frequently will this be used by the users?
    • What is the expected/useful time frame required to solve the problem?
    • Where does the user experience need to fall between form and function?
    • What sort of data is going to be captured?
    • How long does the data need to be retained?
    • How private or public is the solution and the data? (security concerns)
    • What current technical resources are available?
    • What is the “happy path” and what sort of exceptions might occur?
    • How should the user experience the “happy path” and exceptions?
    • What is the expected interface? (Desktop, mobile, phone, audio, visual, or others)
    • How is this expected to grow in user base, features, and access?

    As you can see, this is a lengthy list. It is also just the beginning. The definition of a good solution architecture includes one that is scalable, maintainable, stable, usable, and understandable. However, it also needs to properly and fully address the problem to be solved. Likewise, there is a context to the problem that needs to be understood as well. As an example, check out the sort of questions a building architect should ask: https://maxablespace.com/questions-an-architect-should-ask-a-client/

    Software Architecture Is Like Building Architecture

    I find the best examples to help understand software design and architecture is to look at building a house. There are a lot of ways to build a house. Therefore, there are a lot of questions to be answered before architecting a plan. The link above provides a list of such questions. Software is at least as complex as a physical building. Thus, it makes sense that we need to answer a lot of questions before designing a software solution.

    There is a lot of context around the solution that impacts architecture much like context impacts a building. Think about building a house on a beach and then think about that same house on a mountainside or uneven ground. Then think about the house in a field of empty acres as compared to the middle of a congested subdivision. Context means a lot when architecting a solution. Therefore a good architect will ask questions and dig deep to understand the context around the desired solution.

    Software Architects are a rare breed. There is only a small percentage of developers that grow into architects for a reason. There is a requirement to be able to fully grasp the business context for a solution and then translate that into the technical architecture. Thus, your best approach to starting a solution architecture is to do your homework and understand the problem to be solved and the proposed solution. Only then can you start on the system architecture.

    Check out this article for some more thoughts on getting started with your project: https://rb-sns.com/RB/blog/planning-and-design/

  • Exploring Your Tool and Application Options

    Exploring Your Tool and Application Options

    In the last few years, I have often found myself researching application options and tools a customer is interested in.  This usually starts with a suggested tool or two that they like (or have a few specific dislikes).  Then I am asked to see what is available that is similar but better.  The fruits of those little projects are a good start for this article and will likely surprise you.

    A Target-Rich Environment

    The first thing that jumps out at me when I start these projects is the number of application options that can be found with a search or two.  Even “niche” applications like visitor recording, B2B e-commerce, and database development tools will return several options.  Better yet, most of the alternatives I come across have at least a free trial period of a few weeks while often providing an unlimited free option.  Cost is rarely an issue.  The tools available these days are regularly priced in a way that allows customers to start simple and inexpensive or go all-out for a high-end solution.

    Worth the Investment

    I mentioned a trial period available for most solutions.  When you combine some of the training material often provided with the ability to “play” with these applications the time requirements can become overwhelming.  However, an hour or two will typically be more than enough to evaluate the usefulness of these tools.  At times, you will be able to eliminate options in fifteen minutes or less.

    This time spent perusing your options is well worth the investment.  Your initial list of a few possibilities can grow to several.  Then they can be pared back down to a short list.  At this point,  each solution is likely a good fit (or better) for your needs.

    Evaluating The Options

    The number of viable application options makes the selection process easy to overlook.  When you feel you cannot wrong with any of the available choices, then it is logical to keep your investment small and avoid going deep into the evaluation.  At this point, it is worth looking at the reasons that started the search process.  Some requirements were not being met by the original solution.  They should be verified in the short list of options.  The search process will also provide new elements that are desired in the solution.  That is just the nature of reviewing solutions in any vertical.  Your comfort with a prior solution can keep you from considering what new advances and features can do for your productivity and company.

    Make sure your list of requirements is kept up-to-date with what the research has taught you.  In my case, I am often in a position where I cannot make the call on that list of requirements.  Instead, I make a note of features and enhancements listed by some of the solutions that may appeal to my client.  As part of the review deliverables, I always include these features as an addendum to the requirements list or as “other things to consider.”

    The More The Merrier

    Many tools have a way to invite others into a demo period.  Take advantage of this and find some other people that can give you feedback on the product.  They do not need to spend much time at all in the product.  Instead, they can quickly provide their initial reactions to the features and interface.  This is a great way to avoid making decisions in a vacuum while also sending a form of a trial balloon to determine how open others are to this change.

    I hope these brief suggestions spark you to re-consider your current tools and evaluate how the landscape has changed.  A considerable productivity boost might be just around the corner for you and your team.  Of course, I also am happy to help you in evaluating your options and finding the best tool currently available.  I would love to discuss your specific requirements and how to find the best solution.