DEV Community: Ned Bauerle

The Modern Day Software Architect

Ned Bauerle — Mon, 20 Apr 2020 13:33:25 +0000

The description of a software architect varies significantly in the IT (Internet Technology) industry. You may hear a colleague introduce themselves with a title like systems architect, senior architect, or even chief architect and you wonder to yourself what does that title mean and do I want it?

You are not alone !!

Many business leaders, human resource departments, even technical management share this job title confusion. There are seldom commonalities in how different company's define the software architect's role let alone how software architects are actually utilized within those organizations.

We get so accustomed to the busyness and pandemonium of our daily work, trying to keep up to date with new or updated technologies or projects which are behind schedule that there is seldom a moment of downtime. We never have an opportunity to stop and think about what the role of a software architect should mean in the broad landscape of software development?

Most professions have distinct role definitions and/or education paths. For example an electrical engineer is different than an electrician, a structural architect is different than a builder, a medical assistant is different than a doctor.

Why is there so much confusion in the IT profession architecture role and responsibilities?

To answer this question you have to realize that we are the PIONEERS of this field of study!!! The IT profession is in it's infancy at only 50 years old. Computer science became a program of study around the year 1960. Electrical engineering, on the other hand, started in the 1880s and structural architecture was established circa 2100 BC.

The earliest of software architects would create detailed UML (Unified Modeling Language) diagrams including detailed class definitions. Typically these diagrams were passed to a development team for implementation. This process worked well for hardware or software that was manufactured or created and delivered on a CD, but changes would either require a new product or a new packaged delivery. The process was slow and methodical, typically following "waterfall-like" project methodologies.

In contrast, the onset of the internet allows for cheap delivery and quick updates to software including software that can be used in a web browser without the need for installation. Software can be developed and deployed so quickly that development teams can tackle small bug and feature releases simultaneously. Agile project methodologies paved the way for quick feedback cycles and smaller chunks of work. Creating concise UML diagrams was no longer necessary and nearly impossible to keep up to date with these small changes. Tools like Enterprise Architect by Sparx Systems were developed to automatically synchronize code and diagrams, but in most cases these types of diagrams were just not needed anymore.

So where does the software architect fit in now? Are architects still needed?

At the 2015 SATURN (Software Engineering Institute (SEI) Architecture Technology User Network Conference). Keynote speaker Gregor Hohpe stated "There is always an architecture; if you don't choose then one is assigned." He also mentioned that if you do not plan the architecture before embarking on the solution then the architecture you get will most likely not be the one you want.

Today we find that there is confusion about what differentiates an architect from a lead developer as the architect in many cases is either eliminated as a position or integrated with the development team as a lead developer. We have fallen into a pattern where most projects lack a plan (diagram) of the overall architecture that can be used to communicate choices in development. Developers many times focus only on the task(s) at hand (or in sprint) with little thought about how the task(s) fit into the big picture of what is being developed.

We still need software architects!! We just need to rediscover how the software architect fits into project teams and organizations.

While in the "agile" world the desire to create highly functional teams that are empowered to influence the project there is still a need to create a high level technical roadmap in order to communicate progress throughout our project teams. Without it we run the risk of creating a reputation of recommending work or technologies that executives may not fully understand. In those cases teams get pushback because to them it sounds like it might be work that is not necessary.

We need our software architects integrated with the development team where they can evaluate and adjust to changes in business concerns throughout the process. The architect should be involved early in the process to put together a few meaningful (high level) diagrams which can be used for communication both to management teams as well as development teams.

The size of the project, team, and organization all play factors in how the architecture will be created and maintained. Large organizations are starting to restructure to utilize architecture practices that keep a cohesive technical vision for the company which is then used to advise and unify development teams. Small businesses or projects might not have the capacity to create a separate architecture group so the team may include an architect or conduct mindful architecture sessions throughout the development cycle to create and maintain the architecture.

Traits of a Good Architect

Due to the fact that most architecture roles do not presently have college programs and tools (like CAD for structural architects) we must utilize individuals who have deep experiences and expertise with software development such as the following:

Experienced in Computer Programming - A good architect has been through the good and bad implementations and can use this information to plan out decisions based on experience.

Possess an Analytical Nature - A good architect never stops learning. Technology advances so quickly that in order for an architect to be effective they must keep up with the possibilities.

A Good Communicator - Architects generally need to be able to communicate with both technical and non-technical individuals both verbally and visually through diagrams.

Good at Estimation - Architects should be able to scope out and estimate a project typically before implementation has started.

Both a Leader & a Team player - Most of the planning is done up front. An architect needs to be able to allow the team to influence the choices during implementation and be decisive at times.

Technical Facilitator - During the implementation of a project an architect must remain involved and typically will facilitate communication between the development team, project management, and product owners so that everyone can understand the state of the project.

Publications & Research

To truly advance the profession of software architecture we need to find ways to convey both successful and ineffective solutions for the common problems we solve.
Currently there are hundreds if not thousands of projects in progress who are re-creating solutions that have been successful on other projects, perhaps even experiencing the same failed ideas along the way. If we spend our time re-doing the same work over and over rather than sharing our efforts we will advance very slowly indeed.

At this point you may ask "What can I do about it?" and I say to you ...

Start blogging,
Start mentoring,
Share your knowledge however possible.

Publish articles or share patterns if you are not able to publish proprietary code.

References:

Communicating Software Architecture

Ned Bauerle — Mon, 20 Apr 2020 13:31:51 +0000

The ability to communicate technical software and architecture can be challenging. As a solutions architect, I am quite familiar with the difficulties involved with conveying technical software design ideas to both technical people (developers) and non-technical people including project managers, business analysts, or product owners.

I have discovered that technical people generally stop listening as soon as they think they understand what your are describing and begin to problem solve. "Squirrel", "Shiny Object" ... how many times have you witnessed it? You can never get a complete idea across due to this facet of most developers who have to be quick thinkers (I was like this early in my career). It is not their fault, it is just human nature and part of the job.

Non-technical people may never fully understand what you are describing especially if you assume that they understand some of the technical underpinnings for frameworks, 3rd party software, or even architectural patterns. In those cases you will likely never fully convey your awesome technical software solution which can address their business problem. Instead, you may create a state of confusion and sometimes skepticism will develop instead of trust. When that occurs you will have additional challenges throughout the project as you will likely have to describe each technical choice made during the project in elaborate detail. It can cause a great deal of wasted time.

I have come to find the best way to communicate technical ideas is to make use of diagrams backed by documentation. Representing complicated technical ideas in a diagram is a challenge, but keep reading and you will be amazed at some simple things you can do to improve your diagrams.

Information technology (IT) professions are in their infancy at only about 50 years old (computer science became a program of study around the year 1960). Other professions, like mechanical engineering and medicine, have been around for hundreds if not thousands of years. The IT community should consider "standing on the shoulders of giants" and leverage what others have already learned as opposed to rediscovering it for ourselves.

Let us take a look at how some of these more established professional domains communicate technical subject matter and learn from them. Here are two examples from domains other than information technology.

Here you see a description of the F-35 fighter jet, formerly known as the Joint Strike Fighter.

Different diagrams and descriptions can serve different audiences, each with different needs, but this diagram can be followed by most people.

The next diagram shows very technical information about the human heart. Doctors use this diagram to diagnose and interpret potential health risks. But they can use this same diagram to communicate with their patient who most likely does not have any medical training.

Getting the right information to the right stakeholders is crucial and you can see that very technical ideas can be conveyed in a simple, non-intimidating manner.

Now let's look at a typical software architecture diagram ...

We are pretty good at capturing technical information and communicating with developers and other architects. We have established standard languages and tools for that level of communication, but those standards and tools are not always fit for non-techies who many times are the people that make important decisions which impact the architecture (like where to invest money).

We fail to describe the relevant information and leave out the rest. We fail to speak a language that they can understand. We fail to put them in a position where they have just enough information in order to make good decisions and investments which ultimately helps the team get the job done.

Creating Effective Architecture Diagrams

The goal should be to keep the diagrams simple and easy to understand how things relate. Let discussions and other documents provide deep level detail.

Did you know that your choices for color, shape, lines, etc. convey subconscious meanings that may make the difference as to whether people trust the diagram or even pay attention to it at all. Did you take art classes when you became a software architect? Are you aware of art psychology?

Why Understand Art Psychology?

Art psychology is the perception, cognition and characteristics of art. Different people have different reactions to the same piece of art and different interpretations. For example ... what do you see in the picture to the below?

Did you see a saxophone player or a woman's face? Look again and try to see the interpretation that you did not see the first time.

It is important to get at least a basic understanding of art psychology so that you don't spend a lot of time creating your diagrams and then have them misinterpreted or ignored.

Pre-attentive Processing

Your initial interpretation of the image above is driven by a concept called pre-attentive processing which is the subconscious accumulation of information from the environment. All available information is pre-attentively processed. Then, the brain filters and processes what is important. Our eyes and brains are wired to perceive basic visual attributes of objects without any conscious effort, extremely fast and in parallel.

There are several aspects of pre-attentive processing that you should consider when creating your diagrams as shown in the picture below:

You will notice that you only have to glance at each grid of nine squares and be able to see which block or set of blocks is different. The lesson is: we should use these attributes (size, shape, line width, orientation, position, markings, enclosures, and color) explicitly to put focus on things that are most important in the diagram and worth our attention. This takes some practice and attention because many of us like things to be orderly and symmetrical.

You can find many other examples on the internet if you search for pre-attentive processing.

Color Theory

You probably noticed that color is one of the pre-attentive facets of a diagram, but you should also be aware that which color you choose plays a significant role. There is an field of study called color theory that centers around the emotions and feelings people experience when looking at certain colors. Take a look at the following chart to see how the color you choose can impact the emotions conveyed by your diagrams.

Have you ever noticed that most company logos are blue? Can you guess why? If you want to learn more about color theory you can search the internet for color-theory where you can find all kinds of information about contrasting colors or how groups of colors can also cause different responses.

Imagery

You've heard it a thousand times "a picture is worth a thousand words" and it couldn't be more true. Although it might seem sloppy, perhaps even childish to include icons and images in our documents, the effectiveness of pictures beats words in many cases. We are after all going for communicative effect with our diagrams.

Take a look at the following picture ...

On the left side of the picture are typical symbols used on our architecture diagrams (boxes, arrows, and words). On the right are images to convey the same ideas.

Which is easier to process? I rest my case.

Examples of effective architecture diagrams

There are many other concepts that can be applied to your diagrams and I leave that as a task for you. Once you get started looking deeper into the concepts mentioned in this article you will find yourself in a much bigger world of communicating with art. Applying just some of the concepts will help you improve your technical architecture by leaps and bounds.

Here is an example of what good architecture diagram looks like.

Cisco Systems architecture for wireless integration

The Next Generation of Programmers

Ned Bauerle — Fri, 17 Apr 2020 19:17:10 +0000

Our world is constantly introducing new technology and in many different forms. We have mobile cell phones that are more like mini computers than phones. We are able to pause, rewind, and fast forward our televisions. Our cars have computers to control various safety features and in some cases even drive the car for us. Face it we are becoming more and more dependent on highly technical devices which require complex programs.

It's not a secret that many children follow in the footsteps of their parents when selecting a profession and if you are reading this article then chances are that you work in a technical field. Perhaps you want to teach your children about programming or perhaps you have been approached by a friend or relative who has children interested in learning to program. In any case the intent of this article is to help you get started and provide some resources for teaching the next generation of programmers.

Children are generally hungry to learn. We need to help them out and it is good to strike while the iron is hot, but how do you get started?

I bet that most of you are not elementary school teachers and have not likely gone through training on how to educate young children. Some of you are parents, but teaching children about technology (especially your own) is not the same thing as raising children. So here are a few general tips when teaching children:

Let the child learn. Some will pick things up quickly and some will take a few times before they "get it." Either way is OK, everyone learns differently, just remember to be patient and let them learn in their own way.

It is easy to get frustrated when teaching children, just remember to keep your cool and be encouraging. No one does well when they are being yelled at but rather the opposite will happen and they will only remember that you were upset with them.

As a Cub Scout leader and BSA Scout Master I was trained to use the EDGE method which works really well especially with young children.

Explain what you are going to learn / do
Demonstrate how to do it
Guide or coach them while they try it themselves
Enable them by letting them do it without guidance (only assist when they ask for help, but don't just jump right in, first give hints.)

If you are a programmer or have tried to learn programming then you will probably agree that there is a lot of dry material sometimes very abstract. When teaching kids you have to keep things interesting. Many kids think they are going to write the next World of Warcraft or some other completely complex software. Encourage them to dream big. Tell them that it is a great goal and that there are a lot of things they will need to learn to accomplish such a feat. Let them know that they will need to practice on smaller ideas like a calculator or number guessing game so that they can first learn HOW to program.

One thing that is important is to utilize the right teaching tools and techniques for the right age groups. It took me awhile to figure out that my 6 year old was not going to start programming Java right out of the gate. I then tried to teach him HTML, which he thought was interesting, but I realized that I couldn't easily transfer what he was learning into an actual program. I decided that I had better do a little more research to figure out a good path for teaching my kids rather than taking random stabs in the dark and causing us both to get frustrated.

These are the resources that I found:

HourOfCode has a lot of fun activities and games that you and your kids can utilize to introduce programming concepts. The activities are divided into age groups from pre-readers all the way through high school age. They are designed to be about an hour long each sometimes with an additional follow along activity. I see these activities as great introductions to a lot of different opportunities but there really isn't a lot of consistency from module to module and if you decide that you want to learn more about a specific language or technique there isn't really a guide for that.

Scratch by MIT Media Lab is a free online tool and community that has a lot of great resources for teaching young children and older kids alike. A series of step by step tutorials is built directly into the Scratch ecosystem and you can share your ideas as well as see what others have shared. (seen below)

The interface allows you to drag and drop blocks. Many times with input boxes that represent various programming constructs such as conditional if/then statements, loops, variables, etc. This tool is fantastic for teaching kids how to think logically about how to accomplish certain tasks. The graphical user interface and fun cartoons make it interesting, easy, and fun for kids to learn about programming. If you browse through the community gallery you will find that you can accomplish pretty fantastic things like the game PacMan, or Galaga. Scratch is a great tool for those that want the freedom to create endless ideas, but it will only last for a period of time. Eventually your child will outgrow the interest because Scratch can get bogged down and slow. They can write fun simple games, but they really want to write Minecraft. When you see this happen you know that it is time to start teaching them to program using the syntax of a coding language.

Code Combat is a tool that is a cross between a game and programming. Just like Scratch is great at teaching logic and problem solving using concepts like loops and conditionals, Code Combat expands on that knowledge by teaching about syntax. You are a player in a game where you have to solve different challenges. As you move through the game you earn new objects with different capabilities (commands). For example: the first item you get are boots which allow you to move left, right, up, or down. You have to enter the program and click run to see if you complete each challenge.

One day my oldest was at the point where he wanted to put everything together in his own program. I found the book "JavaScript for Kids: A Playful Introduction to Programming" by Nick Morgan. There is a lot of good humor and the book teaches all of the fundamentals of JavaScript.

When he finishes that book he will pretty much be at the same point that many junior level developers are. I will likely introduce him to NodeJS followed by Angular 5. I am certain that he could work through the tutorials even now, but he is excited to finish the book because at the end he noticed that they have built the game snake.

I hope that you are able to get some information from this article that can enable you when teaching your kids (or your friend's kids) how to program and at least an idea of what other things you can find to help them in their journey.

Good Luck !!

Create a Culture of Innovation

Ned Bauerle — Fri, 17 Apr 2020 13:20:43 +0000

It can be exhausting trying to keep up with market trends, particularly driving new features or improvements, using traditional business driven practices. Customers demand products that are evolving at a quick pace or they get bored and may move on to a competitor's product. The goal today is to deploy new features, fixes, and improvements as quick as possible in order to keep up with customer expectations.

As agile methodologies and good DevOps practices create a foundation to quickly develop and release products many companies are realizing that they need to increase the pool of ideas to keep up with the pace. Several Agile LEAN frameworks are designed incorporate a sprint of innovation and planning such as the SAFe (Scaled Agile Framework) where every 6th sprint is exactly that.

The point is that you need to utilize the talent you already have within your organization, your product development teams, by creating a culture of innovation. Let's look at a few examples of companies that lead the pack for innovation practices such as Apple, Google, and Netflix.

Apple has been at the top of the list for companies that are the most innovative for many years running. They attract amazing talent because people genuinely want to work on their products. They encourage everyone to contribute new ideas and have no limits on how they invest in innovation. Good talent is attracted to Apple rather than Apple seeking out the talent.

For a long time Google had 20% time, where 20% of working hours from each employee are expected to be applied to innovative ideas that may benefit google.

Netflix has a culture of fully trusting employees to do what is right for the company even going as far as not having required hours of operation or PTO policies. They focus on hiring the right people and trusting them to do what is necessary. There is room to experiment and makes mistakes without repercussions.

Smaller companies and organizations who are just starting to cultivate an innovation mindset find it hard to implement strategies similar to these behemoth size organizations who have enough staff to cover regular operations while letting them innovate part time.

There are other less intrusive ways to start building a culture of innovation, one of which is holding an innovation event or hack-a-thon with your associates.

Get started by first establishing a definition for Innovation in your organization, emphasizing that innovation does not always mean creating something new, but rather it is about creating new value.

Service-based architecture patterns such as microservices enable applications and functionality to be mixed and mashed in ways that would have been difficult as recent as 5 yrs ago. Your development teams know how your applications are put together and what service APIs are available.

Encourage your team to think about the services and applications that they have created and how they might be able to leverage services from different products to create new value. You will be surprised at the ideas that the team(s) will produce about how those services might mix and match to create new value.

Attracting good talent for your organization is challenging and keeping up with customer expectations will quickly exhaust your ideas. Offering opportunities for innovation and continuous learning are ever more important to set your company apart from others. Get started planning your own innovation event today !!!

Planning a Company Innovation Event

Ned Bauerle — Fri, 17 Apr 2020 13:18:26 +0000

Regularly holding innovative events (at least annually) can have many benefits to your company and your associates. Associates get to learn and grow together and you can advertise it as a benefit which can help when recruiting good talent and/or retaining associates you already have.

Holding an event will be an investment in your organization and in your associates. It will be difficult to calculate the return on investment for the event so realize that it will more likely be an investment to your company culture. Innovation events have the potential to generate new product features that you may have never conceived. Your associates will feel that you are investing in them by giving them an opportunity to learn something new and ultimately allowing them to prove some of their ideas to you.

It will be important that the management completely "buys" in to the event and exhibits positive energy. Avoid setting any expectations for yourself or others about any certain outcome; rather, go in with an open mind and see what the team can do for your company. People genuinely want to do a good job and help the company to thrive.

Before you communicate the details of your innovation event to your associates there are a few things you need to prepare ...

Planning

You need to determine what dates you will hold the event and how long the event will be. It is important to allow time for your associates to innovate as teams for this type of event, typically with dedicated consecutive days to become fully engrossed in their project. Two to four days is a good length of time. If it is hard to take four consecutive days off then you might break it into two sessions with 2 days each week. Identify dates where typically the business is slow so that you can allow the teams to focus on innovating without being distracted by other business needs.

We plan our innovation events to be four days at Leading EDJE. Three days of full on development and then on the fourth day we use ½ the day to prepare presentations and ½ the day to present their projects.

Once you block off the dates for your event you can procure a location for the event. Find a space where the team(s) won't have any interruptions, typically a location away from the office is best or at least in a space that is not typically used for daily work. There are some innovation spaces that are designed and decorated to inspire, many of which provide treats to keep energy levels up and to promote creativity.

At least 6 weeks before the event you should choose a theme and/or title for the event. Having a theme will set the stage for your event and allow you to differentiate year after year. A cool or witty title like "Monster Tech Mashup" or "Hack Fight" can start creative juices going and might also put a little competition into the event. If you are drawing a blank there are tools like that can help you.

You can drive excitement for the event by making it a competition. You might supply a prize for the winning team, or you perhaps just bragging rights. If you plan to make it a competition you will need a way to measure and/or compare ideas. At Leading EDJE we typically ask the teams to evaluate the other team's ideas using a scorecard (based on the theme). You should determine what criteria will be used in the scorecard and if there are any surprise categories that will be kept secret until voting occurs. Once you have a way to compute team scores you should prepare a message describing the guidelines so that the teams know what is expected. You can then distribute the guidelines prior to the event which will ultimately avoid sore feelings that a team may not have understood the rules.

Send a message to your associates describing the event and requesting everyone to participate including the guidelines.

5 to 6 weeks before the event ask your associates to come up with and submit project ideas that are company and / or industry related. If you don't have a flurry of project ideas you should hold a brainstorming lunch or happy hour to promote collaboration. You can have tables or posters around the room where people can gather and job down technologies they would like to work with, improvements to your products, and ideas they have seen in other industries.

Make sure you tell the teams how much time will be available to build out their idea, not that they should restrict themselves to ideas that can't be fully implemented in the allotted time frame, but ideas that can be prototyped for a demo. The teams will also need to have an idea about how much money can be applied for project assets. They should provide a list of anticipated hardware, software, and network access as part of the project submissions.

4 to 5 weeks before the event you will need to establish teams. You can either assign teams and allow them to select from the list of project ideas (this approach allows you to align people who typically don't work together for example), or present project ideas and allow associates to sign up for a team. If there are too many project ideas then you will need to have a process for narrowing the list down and you may need to establish team guidelines for minimum and maximum size.

2 to 3 weeks before the event 'and after the teams have been established you should let them know that they need to get together before the event to plan their approach. By meeting prior to the event the team members will be able to do some research and hit the ground running on the first day. The team should also solidify what they need for the project (hardware, software, network access, etc.) so that you can get it prior to the event.

1 week before the event confirm that everything is ready and that you have ordered and received any of the requested assets needed by project teams. If you are providing hardware, software, food, treats, drinks, etc. make sure that you have everything set for the first day. Confirm that the location is set as you are expecting and that the proper network connectivity is in place. Make sure that you have tables and chairs configured in a way that teams can collaborate but are far enough from other teams that there isn't too much disruption. Double check to ensure you have enough power strips and extension cords that can reach each team. Make sure that your awards, trophies, and voting ballots are ready for your showcase day.

Running the event

You should kick-off the event on the first day, perhaps providing breakfast. Let the teams know that you are excited to see what they come up with and that they should let you know if they run into any issues with the requested assets you have provided so that you can help to resolve them. Try not to tie up much time by making long winded presentations, just let the teams get right to it. You should budget a little extra money in case there are game day purchases that you need to make. If you are conducting voting you might put up slides to remind the teams how they will be compared to each other when determining the winner.

The Showcase

At Leading EDJE we prefer to have the teams demonstrate their idea at the showcase and request that each team member participate as a presenter for part of it. Once the presentation is complete the other teams vote using a scorecard and commonly an additional team of managers or executive leaders provides a vote. We use one scorecard per team because commonly teams are varying in size.

An alternative to team voting would be to select a panel of voters (for example some of the executives or partners). Teams present the projects and ideas to be scored by the panel. If your company is medium to large then it is likely that the executives may never get to know the teams or their abilities on a personal level but if they get to participate on a panel in the innovation event then they can directly interact with your team. If you have ever tried to sell ideas upward you probably understand that it can be difficult to get buy in if the upper management is thinking of your team as a commodity rather than people, putting a face and showing off their capabilities can help to break down those barriers to communication.

Once the presentations are complete finalize the scoring and announce the winners. Present any awards or trophies.

After the event ... (share the knowledge)

Ask the teams to record what they learned, the idea they had, and the technologies they used on a company shared space or wiki.

All in all we have had great success with our innovation events at Leading EDJE. Our entire staff is excited every year as the excitement builds for the event. The ideas produced are never shy of amazing. We love to see what new and creative ideas our team has every year and it is a ton of FUN.