Tag: design

  • 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/

  • Keeping The Agile Development Approach Flexible and Increasing Velocity

    Keeping The Agile Development Approach Flexible and Increasing Velocity

    The Agile development approach is a hot topic and has been for a while.  Although it is adopted in a lot of shops and well-documented, there are still some issues with it.  The way we implement the Agile approach can defeat the purpose of a flexible model that allows a high velocity of production.  That assumes you have enough resources to effectively do more than one thing at a time.  However, there are some ways to adjust your scrums and sprints to get the most out of this methodology.

    Agile as Small Waterfall

    One of the flaws I have come across is that teams treat a sprint as a short waterfall process.  It does include all of the same steps as the waterfall approach (gather requirements, design, implement, test, deploy) but does not need to be as linear.  For example, a waterfall approach to a sprint would be a few days for requirements, then to design, then implement for a while, then test, and end with a deployment.  All you gained in this is reducing the scope of the requirements and what is deployed.  I am over-simplifying a little bit.  However, this is close enough to a lot of sprints I have seen.

    The productivity problem is that you have resources during the sprint that are not used.  Testing is not done until the end, so testers are idle at the start.  Designers are not needed much during implementation, so they are almost unused.  Team members do a lot of work at a high pace during their portion of the sprint and hang around the rest of the time.  You can use that spare time for training and skills improvement (not a bad idea), but there are better uses of your resources.

    Continuous Progress

    The goal is likely to keep all of your resources working on a steady and constant basis.  This can be partially achieved by including everyone in every step.  It makes sense for testers and developers to be involved in design and designers engaged in implementation, testing, and deployment.  However, this is almost like busywork in some of those cases.  A better approach is to overlap your sprints.  This is easy to do with multiple teams.  Nevertheless, it can be accomplished with a single unit as well.

    The effect is that you will have more than one sprint active at a time.  Multiple teams will have this, but a single group may as well.  With multiple units, a productive approach is to have members be a part of more than one sprint at a time.  The implementation team will be the only group that tends to have a single sprint focus most of the time.

    Overlap For Productivity

    Let’s use a two-week sprint as an example of how this works.  Sprint A starts on week one and requirements are gathered (from the backlog).  The implementation and testing team go over the items for the sprint and provide feedback, estimates, and ask for clarifications as needed.  This is the first few days of the sprint (we will assume two).  Next, we move into implementation.  For this example, implementation is six days which leaves two for integration testing and deployment.  That is not enough time for sufficient testing so we will have our testers running through scripts where possible as tickets are completed during this phase.

    The designers will be supporting the implementation phase, as needed.  However, they will also be looking ahead to the next sprint.  The design team can dig deep into designing for the next sprint and use this time to get feedback on design decisions as well as poll customers/users.  That should make it easy to keep the selection and clarification part of the next sprint go smoothly (maybe a day instead of a couple).

    As we move into testing, then the implementation team and designers will start work on the next sprint.  They will be selecting and clarifying tasks while the testers test.  As we move into deployment for Sprint One, we will also be working on implementation in Sprint Two.  Rinse and repeat.  The overlap of a few days will help keep designers busy and the developers implementing.

    If you have two or more teams, you can overlap implementation, keep design short and assign designers to possibly several sprints at a time.  This will also allow for more design time to be allocated to each sprint.  That will pay off in clarity around requirements as well as reduced design related flaws.

    Minor Tweaks

    As you can see, these changes are not earth-shattering, nor are they complicated to introduce.  Your scrum master and designers might have a little more asked of them.  Nevertheless, the payoff is worthwhile, and they will find a rhythm with this process early on.  It also helps avoid a roller coaster of activity that can often occur with team members when you do not find ways to keep them busy and focused throughout a sprint.  Better yet, this is an easy change to try for a few sprints to see if it works for you and your team.

    I would love to hear other suggestions and feedback on how your attempts at improving your agile development velocity turn out.  We can all learn from the successes (and failures) of others.

  • Creating an Effective RFP

    Creating an Effective RFP

    Sooner or later we all need to solicit proposals that provide solutions to a problem.  This might be a request for an application, a service, or products.  It should come as no surprise that an effective RFP process accurately defines the problem.  However, there is more detail that makes up an effective RFP.

    What is a Well Defined Problem?

    The challenge of a technical RFP is often the language required to create one.  The technical staff provide input (or possibly the entire response) to an RFP, so it is essential to communicate to them directly.  Miscommunication can make responses invalid or worse.  However, the writers of the RFP are usually on the business side of the equation.  This is not an insurmountable issue.  It just requires attention to the details that matter to an IT solution.

    The key is in the details.  A problem definition needs to include these pieces to provide the context required for a solution rather than just an answer to a question.  For example, an RFP that defines the problem as a need for a website with a “contact us” form is overly simple.  There is no context for a useful solution.  Think about how the details below can help respondents craft a more meaningful response.

    • Who are the primary users?
    • When will it be used? (business hours, 24/7, etc.)
    • What is the expected response time for the pages/functions?
    • Are there constraints or limits to the technology of the solution?
    • Will it have to scale? To what level?
    • How soon is the solution needed?
    • What sort of budget do you have?
    • What kind of company are you?  (line of business, employees, sales)

    These details may seem like providing too much information.  Nevertheless, these provide context for the solution.  These details will help the providers craft a solution that meets your needs.

    Know The Respondents

    As part of your RFP, you want to make sure you have the right people for the job.  A good RFP document provides a lot of detail about your company so it is only fair to request details about the respondents as well.  In a similar sense to the problem details, a good RFP requests several facts from the respondents.

    • How long have you been in business?
    • What does your typical customer look like? (size, business, focus, etc.)
    • Have any major changes to the company structure occurred recently? (merger, acquisition, etc.)
    • What sort of support staff do they have?
    • What certifications, audits, and assessments have been done on the company?
    • Can you provide some good references?  For example, customers that were provided a similar solution?
    • Describe the processes you use to ensure quality.

    An Effective RFP Takes Time

    Do not underestimate the value of your problem.  If you have a strong enough desire for a solution to search for proposals, then make it worthwhile.  Spend the time to properly detail your problem and allow for respondents to take their time in crafting a response.  I hope these items have helped you create an RFP process that works for you and finds a perfect response.