DEV Community: iotcloudarchitect

What about Agile Development?

iotcloudarchitect — Thu, 06 Jan 2022 15:22:26 +0000

This article shall give you an overview of agile development and help you decide whether Scrum or Kanban can meet your needs.

But, first of all, a clarification about what agile means.

12 Principles of Agile Methodology

In 2001, a group of experts in the field of software development methodologies and frameworks got together to define the 12 principles of the Agile Manifesto:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity -- the art of maximizing the amount of work not done -- is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Building Blocks of Agile Development

Based on my experience, and completed by the 12 principles, I would propose the following building blocks of agile development depicted below:

In a nutshell a short description of the building blocks:

Objectives

The objectives define the root cause of all the sweat and hurt when building software. The main aim should be a satisfied customer. In our case - with regards to agile development - the customer would be happy if he could bring in his requirements and needs, at any time, with any impact it means to the current development situation. Also, he appreciates the continuous delivery of the software he requested at short time intervals.

Participants

One of the basic ideas of agile development is that the customer, business people, and development team work jointly together to create the best solution possible, meeting the requirements.

Collaboration

The beforehand mentioned participants will work together and will exchange their ideas regularly. Business people and the development team should meet in the best case on a daily basis for at least a short synch about progress or discuss problems.

New requirements or changes of existing requirements should be discussed and evaluated which impact they might have on the existing implementation.

It is essential that all participants work together and support each other to get the best result possible.

Also - regularly - the participants shall reflect their way of working together to optimize the process continuously.

Planning

All requirements of the customer (mostly functional) and non-functional once shall be collected in a backlog.
There, all requirements can be estimated and prioritized.

Based on the estimations and available development team size, the (constant) workload can be defined to reasonable plan the following implementation of features.

Visualizing the tasks or user stories the team is currently working on creates transparency. It helps to track the progress and to measure the iteration's quality.

Development

Agile development requires a self-organizing team. The team members are specialists and bring in their know-how, experience, and motivation.

It is beneficial to have players with excellent technical skills who can utilize the necessary technologies to implement the requirements perfectly.

A key aspect in agile development is to focus on working software. At the end of each iteration, the result should be a software increment covering the requested requirements.

In order to be able to bring in the working power ideally, the development team should have the ideal environment. Everything should be in place from the code editor and the code repository until the cloud-driven pipelines with automated testing to optimize the development process.

Focusses and Objectives of most agile frameworks

Self-Organized Team

It is crucial to have a team that works without the need for instructions in agile development. Every team member knows the process and the dos and don'ts and acts accordingly.

Pull-Principle

The idea is that each development team member can take (pull) a job according to his availability. This means that everyone commits to a specific task at a particular time.
No one will push tasks to a developer; instead, jobs are accepted and taken by the development team members.

Software Increment Orientation

The result shall be shippable and working software at the end of each job or iteration.

Transparency

Visualizing the tasks and their state is the key to making optimization opportunities visible and increasing efficiency.

Measure Progress

It is essential to track and monitor the progress of the job or iteration.

Popular Agile Frameworks

Following, a short description of two popular agile development frameworks: Scrum and Kanban.

Scrum

Scrum comes with a defined process as depicted below:

The product owner collects all requirements in a backlog, prioritizes them, and plans a manageable amount of work in a defined time (sprint). Therefore, it is often used to develop a new feature or an entirely new product.

For the planning of a sprint, beforehand, the effort of the work will be estimated by the team in a virtual entity called story points. These story points will be used during the sprint to progress the team's velocity.

At the end of each sprint, the results are software increments, e.g., new features or functions in an app.

Also, in Scrum, there are clearly defined roles of the participants, and due to its restrictions, it is supposed to be easier useable for teams with less experience.

Kanban

The primary purpose of Kanban is the visualization of work. Like in Scrum, the requirements (stories) are collected and then planned for implementation (to do). The stories will be written on cards and put onto the Kanban board as depicted below.

In Kanban, an essential principle is to focus on a sensible amount of work that the development team can achieve. Therefore, the number of cards in the board columns is limited. The current number of cards in a column is called the work in progress (WIP) and shows the team's current velocity.

Like in Scrum, the result of each of the stories should be a new software increment.

In contrast to Scrum, Kanban does not require specific roles and is not as restrictive. Therefore it is more flexible and can be used for reactive jobs, like planning a bug-fixing for productive software.

Do you need an agile framework?

The following diagram shall give you help with deciding whether you need an agile framework:

Summary

Which is the proper development framework for your project? I can't tell you. But I hope this article gave you some insights into whether it could be an agile development framework.

Photos on Unsplash

What about a blockchain?

iotcloudarchitect — Tue, 28 Dec 2021 10:17:10 +0000

The basic idea of a blockchain is to store information immutably, transparently, and traceable inside a duplicated and distributed ledger. The ledger consists of blocks, and every block is cryptographically connected to the previous block. Each block contains transactions that the participants of the blockchain beforehand validated.

This article gives a high-level overview of the concept of a blockchain used for transactional systems but not a detailed step-by-step instruction about implementing the technology.
Furthermore, it shall help you decide whether your system or idea could use a blockchain approach.

Centralized Transaction Processing

In centralized transaction-based solutions, at least one central instance acts as a gate for decisions or manages essential parts of a process. Everyone interacting with it has to trust these middlemen.

Let's take an example.

You want to give $100 to Peter. To cash transfer the money from your bank account to the bank account of Peter, you have to utilize financial institutions, e.g., banks, to process the transferal. In this case, your bank and Peter's bank are middlemen, which means they are central instances of the process. Also, between both banks, there is another middleman, the clearinghouse, which establishes the trust between both banks.

Following, the steps of the process depicted above:

You will instruct your bank (B1) to send $100 to Peter's bank account.
B1 will first check whether you have at least $100 you can send.
Next, B1 will tell the clearinghouse (C) to transfer $100 to Peter's bank account.
C will take the $100 from B1, contact Peter's bank (B2), and move the money.
(B2) will put the $100 into Peter's bank account.
Peter finally got the $100.

The process perfectly shows that the banks are middlemen to you and Peter. And between the banks, the clearinghouse is the middlemen.
A lot of intermediaries, right?

Blockchain-based Transaction Processing

Let's see how the same process would work on the blockchain cryptocurrency Bitcoin:

Following, the steps of the process depicted above:

First of all, all participating nodes must have the latest version of the ledger containing all blocks each containing transactions.
You will now send one bitcoin to Peter utilizing a (transaction) node (A).
A will verify whether you have one bitcoin that you can send and if everything is okay, it will bundle the transaction into a block.
The miners (B, C) validate the transaction using algorithms (mining process).
After all miners agree, the block will be put into the blockchain on the ledger and every node gets an update. Peter received one bitcoin from you.

As you can see in this process, no single entity is responsible; all nodes together validate and decide about the transaction based on cryptographic security and clearly defined methods.

Trust is key

A blockchain can substitute existing systems, but it has to, first of all, create trust. The participants need to trust the implementation of blockchain technology like they did it with the middleman concept.

Here is how blockchain creates trust:

The next chapter describes the benefits mentioned above.

Benefits of a blockchain approach

Following, the most obvious benefits:

Redundancy

The ledger is duplicated and distributed to every participant. Also, each update will be synchronized to every copy of the ledger. Therefore, no one can delete the ledger.

Cryptography

A blockchain network self-organizes itself. It uses consensus algorithms and cryptography to secure transactions between multiple partners without the need for a trusted middleman in between.

Immutability

A blockchain records the blocks and their bundled transactions immutable by design. Once a block is attached to the ledger, it is cryptographically connected to the previous block. The nodes will immediately detect changes of blocks.

Traceability

Everyone with a copy of the ledger can verify which transaction happened at which time. The entire history of actions is recorded, not just a snapshot.

Transparency

Every transaction is processed the same defined way and is documented and validated by the nodes. Inside the ledger, all blocks are recorded and therefore visible to everyone.

Do you need a blockchain?

The following diagram shall help you to figure out whether your idea or system could be driven by a blockchain approach:

Real-live examples for blockchain solutions

The following diagram shows potential real-life solutions derived from the benefits a blockchain approach offers:

For sure, the examples mentioned above are not collectively exhaustive. There are a lot more. But a reasonable solution should always take care of at least 2 or 3 of the benefits a blockchain approach offers. Otherwise, you do not need fully-fledged blockchain technology.

Summary

The worst thing you could do is create a blockchain system without a specific problem you are trying to solve, just because it is en vogue to have a solution in your product store. It is not just how you store data; it is about creating an ecosystem that self-organizes itself in a highly secure way. As always: think problem first, then solutions.

Photos on Unsplash

Becoming a great solution architect – Chapter 3 – The Responsibilities

iotcloudarchitect — Thu, 23 Dec 2021 07:07:56 +0000

1 - Get All Involved, Aligned, and Committed

The fundament of an excellent solution architecture is to
understand the problem holistically. It means understanding all stakeholders’ requirements, all constraints, and formulate the essence of a system that solves the problem in total.

The solution architect must also set up a collaboration framework to consider, debate, and determine the solution concepts. Close communication with the key stakeholders is essential since agile development offers opportunities to adjust the solution.

He analyzes the risks and costs, monitors the quality, and keeps an eye on time planning and resources with the product owner or project manager.

2 - Scope, Simplify, and Structure the Problem

In the beginning, the solution’s scope must be clear, which helps to focus on the essential parts and avoids spending time on unnecessary topics.

Be clear about what the solution will cover (and what’s out of scope).

The solution architect slices the problem into relevant parts to identify processes and functions and transform them into a manageable solution component model.

Simplifying and structuring is key.

An essential point of the solution architects’ work – besides the “pure translation” from functions and processes into technology – is to draw a picture of the envisioned solution, so every stakeholder understands.

The Big Picture of the solution helps to fight for the same thing.

3 - Select and Evaluate the Key Technologies

An essential part of a solution architect’s work is to choose and evaluate the best fitting technologies the solution runs. One step here might be creating a prototype for a proof-of-concept to validate the technology regarding different aspects like performance, stability, and scalability.

Furthermore, he advises the technology stack covering the entire end-to-end perspective.

Besides, the solution architect identifies the potential cost of the environments, significantly what the monthly fee is for operating the solution after go-live.

4 - Consider Solution Design Principles and Architecture Design Pattern

Like a professional craftsman, the solution architect utilizes guides, tools, and best practices.

There are a lot of Architecture Design Patterns already published across the internet, covering different aspects.

Here, some examples of cloud-specific patterns (see in detail in Bill Wilder’s book “Cloud Architecture Patterns” at O’Reilly’s):

Horizontally Scaling Compute Pattern – providing more instances of one service in parallel
Colocate Pattern – deploying components that work together in the same region/data center
CDN Pattern – Distribute content across the internet in regions close to the user

There are a lot more, also “traditional” patterns like:

Client/Server – one service provides data, the other one consumes
Microservice – a (web) service which covers the aspects of a single business domain with dedicated data storage and clearly defined interfaces
MVC – separation of a user interface application into model, view, and controller logic

Besides the patterns, the solution architect applies solution design principles like the following:

Scalability – a solution must be capable of (dynamically) increasing itself according to the demand (Horizontal or vertical scaling)
Security – a solution must be secure regarding the communication between components, data in rest, accessibility of service administration, etc.
Resiliency – a solution must be capable of being stable also at times of intensive load and can recover from exceptional states
Fail-Over Capability – a solution must be able to continue working even if instances of components are not available
Single Point of Failure – it must be clear which components are crucial to mitigate potential risks
Accessibility, Availability – a solution must be deployed as close as possible to the users (low latency) and must guarantee a high up-time

5 - Comply with Non-Functional Requirements

Besides the functional requirements, there are several other things the solution architect is considering for the solution listed as follows (examples):

Cost Optimization – finding the perfect mix of technologies and infrastructure to solve the problem, and to spend a minimum of money
User Experience – supporting the UX team to find the ideal user interface, guiding users intuitively through the solution
Quality Assurance – support with (automated) testing of the solution’s components to deliver high-quality applications
Performance – support with load testing to ensure the expected number of concurrent users and client services

6 - Consider Staging Environments and Enterprise Architecture

The solution architect advises the staging concept and the required technology fundament in dev, test, ref, and prod environment.
Also, supporting the introduction of continuous integration (CI) and continuous deployment (CD) might be essential.

He considers the enterprise services in the on-premise data center, mainly applications about data exchange, identity management, and handling regulatory requirements.

Besides the processes, the solution architect considers the interfaces of enterprise applications the solution needs to communicate and give advice for the integration to the development team.

Summary

All the responsibilities mentioned here are the essence of my personal experience and opinion and reflect best practice guides from other solution architects. In case you believe this article can help others sharpen their focus, or reflect themselves, feel free to share it.

Hope to see you again in the next chapter!

Photos on Unsplash

Become A Great Solution Architect – Chapter 2 – The Requirements

iotcloudarchitect — Wed, 22 Dec 2021 17:10:45 +0000

1 - Vision

A great solution architect can draw the big picture of a solution in a fashion all stakeholders can read and understand. And he can present it, including all the objectives and how every stakeholder can contribute.

A common understanding of the solution is essential for the success of the entire project. Because, if some stakeholders have a different opinion or interpretation of the solution, this could cause a problem.

Transparency is a crucial success factor.

So, if everyone in the project team, from the product owner over the business analysts to every developer and operational staff, can tell you the same story about the solution, the solution architect did a great job.

2 - Communication & Presentation Skills

A great solution architect is a great communicator since this ability is a vital part of his competence. Along the entire road to successfully realize the defined solution, there is a lot to discuss, negotiate, and specify with every single stakeholder. Therefore, the solution architect listens carefully, explains properly, gives valuable advice, and understands the stakeholders’ intentions.

Being present on the project – even virtually – gives stakeholders confidence in your work.

Presenting the architecture, results of proofs-of-concept, and sharing insights about the progress of the implementation process and the quality of deliverables is an essential part of his work.

Do good things, and tell about it.

3 - Organizational and Leadership Skills

Of course, the solution architect does not play the role of a project manager on top of his work. But, since he gets directly involved due to his essential position inside the project, he has to deal with deadlines, given resources, and must be focused on the project’s results. His objective is to succeed in achieving the milestones.

Go the extra mile – it’s more than merely writing a concept and test implementation.

Besides this more visual part of work, a great solution architect mentors the lead developer and, if necessary, parts of the development team. His objective is to get an impression of how the development team implements the architecture. In case there is a mismatch, you better know about it in an early stage.

Mentor the team which implements your ideas.

4 - Modelling Methods, Frameworks, and Best Practises

A vital part of a solution architect’s work is to document the architectural approach in a standardized way. Here, architecture design patterns can scaffold the fundaments of the solution architecture.

Modeling methods like the Unified Modelling Language (UML) depict the solution architecture in a fashion the development team understands and uses it as the basis for their implementation.

Standards are your friend.

Since more and more software projects go the agile way, the solution architect is familiar with frameworks like Scrum and Kanban, which help to organize the development and delivery process but also found the planning of product features.

The solution architect is continuously looking for best-practice approaches and game-changing tools and technologies.

Stay open to new impressions.

5 - Knowledge of Software Development

At the end of the day, the development team will implement the architected solution. It is, of course, not part of the solution architect’s job. But, it is beneficial to understand how developers think, how they act, and what things they do not know in detail.

Software developer experience helps to assess the developers’ progress and quality and offers the possibility to support the team.

Besides, a solution architect shall be able to code on its own – at least for technical evaluations or entire proofs-of-concept. Therefore, the knowledge of at least one of the top three popular programming languages will boost his possibilities. We are currently (2020) talking about JavaScript (EcmaScript 6, TypeScript, NodeJS), Python, Java, and C#.

Coding skills are helpful, but you don’t need to write production-ready code.

In case there is a need to assess code quality, the solution architect could dive in, but then his knowledge of the particular programming language must be excellent.

6 - DevOps

It defines an approach to shorten the software development life cycle and provides continuous delivery of high-quality software with the help of a dedicated toolchain.

Since the solution must finally run in the production environment, the solution architect, the development team, and the operations team shall work together to find an excellent process and to select the vital supporting technologies.

To ensure that, the solution architect helps with the setup of DevOps processes, like the planning of the building, automatic testing, packaging, releasing, configuring, and monitoring.

The objective is to define an (automated) process to build, test, and deploy properly working software.

The solution architect considers the DevOps approach during his architectural work by examining the staging environments, e.g., development, testing, acceptance/reference, and production.

7 - Analytical Skills

A great solution architect is an excellent listener and structures the insights he gets accordingly. Collecting data, interviewing stakeholders, and reflecting the gained information will help get a holistic picture of the problem.

Based on this treasure, he can focus on details to fully understand the business needs and processes.

Another essential attitude of a great solution architect is always to reflect and question the information he gets.

8 - Tech Domain and Industry Knowledge

An experienced solution architect has a lot of expertise in different types of projects enabled by various technologies. Furthermore, he specializes in some way towards key tech domains, e.g., IoT, Cloud, AI, Big Data, etc.

There usually are a lot of best-practice approaches, architecture design patterns, and out-of-the-box examples well known in these tech domains. Furthermore, an experienced solution architect gained a lot of knowledge from proofs-of-concept and knows about the pitfalls of key technology implementations.

Experience with technology stacks is significant.

Besides the knowledge of specific technologies, it is beneficial to know about the processes, methodologies, and do’s and don’ts of particular industries. Industries like finance, healthcare, energy, automotive, etc., have their own rules and restrictions. Especially in the phase of interviewing or reviewing the business (functional) requirements, domain knowledge can help identify mistakes in specifications.

Industry know-how is beneficial but not crucial.

Summary

All the requirements mentioned here are the essence of my personal experience and opinion and reflect the demands of companies hiring solution architects. Of course, it can’t be a collectively exhaustive line-up, but I deem it touches the most prominent topics.

In case you believe this article can help others sharpen their focus, or reflect themselves, feel free to share it.

Hope to see you again in the next chapter!

Photos on Unsplash

Become A Great Solution Architect – Chapter 1 – The Mindset And Attitude

iotcloudarchitect — Wed, 22 Dec 2021 08:09:07 +0000

1 - Understand the problem

The first essential thing I want to mention right at the beginning is: Think problems first, then solutions!

Please don’t start thinking about technologies before you didn’t understand your customer’s problem precisely. Thinking in solutions from the start might guide you in the wrong direction.

Problems might seem the same from a first look; however, the solutions are always different in the end!

It would help if you always take your time to study the requirements in detail and be not afraid to ask and challenge the elements with the product owner or business analyst.

Since the solution architect is the binding element between the functional requirements and the technical solution, he must understand both sides to make the right decisions.

Better to ask one time “to often” than to continue without precise understanding!

If you don’t follow the advice, you might get into trouble in a later phase of the project since there were one or more crucial things you did not see or did not spend enough detail on it.

2 - Stay High-Level

The solution architect creates a high-level solution architecture that holistically considers all requirements; nevertheless, it describes the solution from a helicopter perspective.

Based on the solution architecture document, and the selected technologies, the lead developer creates a technical concept regarding the implementation.

There might be some cases where the solution architect might be the only one familiar with a chosen technology, and so he also needs to write the technical documentation. But this should happen for the minority of cases since the development team must do the implementation.

3 - Be Open For Feedback

Live is a continuous journey of gathering knowledge, and due to this fact, each individual can make mistakes. Moreover, no one can know everything. Therefore, the solution architect should be open to qualified feedback.

Feedback is a gift! (even it turns out later that the input wasn’t adequate)

It is always valuable to consider a second meaning, especially during the solution architecture documents’ review process. Two eyes see more than one, right?

A good example is, for instance, the feedback from the operations team. If they complain about the chosen technologies, this could turn out into a real problem, since those guys have to run the solution after development.

Besides, it could be a problem regarding implementation quality, if it turns out that the development team does not own the appropriate skills to realize the solution. In the best case, qualification training before the start of implementation is mitigation here.

4 - Stay Open-Minded

A solution architect is continuously scanning new technologies, methods, processes, and tools that could help him architect kick-ass solutions. Still, the new stuff must pay into problem-solving.

The inspiration comes, among others, from reading other architects’ blogs, studying best practice approaches, or try real-world examples of solutions based on new technologies.

Furthermore, attending conferences or workshops can enlarge one’s horizon, and sharing knowledge inside the company would be a fruitful option.

A solution architect must have a broad knowledge of different technologies. But he should have at least one specialization, something he is a real master, e.g., IoT, Cloud, Big Data, AI, etc.

5 - Feel and Take the Responsibility

The solution architect is responsible for not less than the success of the running solution. Sure, he does not code on its own or setups the production environment, but the product owner will blame him for missing the objectives in the end.

Consequently, the solution architect should take an eye on the quality of all the project’s concerns, and especially the solution’s matters.

6 - Eye for Quality

After handing over the reviewed solution architecture documents, the implementation by the development teams starts. Up from now, the solution architect must rely on the experience, knowledge, and leadership skills of the lead developer.

For example, the solution architect should monitor the progress and efficiency of the development team to support them proactively.

7 - Leader and Motivator

Part of the job of a solution architect is to guide, mentor, and challenge the development team. Especially with the lead developer, he should have a close relationship.

The lead developer is the one to work tightly with the developers, and his motivation and experience will directly impact the work of the entire team.

8 - Keep Agile, but also say: "No!"

During the implementation of the solution, there will come requests for changes. The solution architect must verify the claims and prove what kind of difference it might have on the current architecture or the ongoing development.

In case it turns out that there would be a need for an impacting transformation, he should take a clear position and evaluate potential negative results.

The solution architect is responsible for the entire solution! Due to this fact, he should not try to be everybody’s darling, since this is not realizable. It’s about the art of making compromises.

Summary

I won’t say that if you cannot cover all the aspects that you are not a good solution architect. Maybe I also forgot an element you would expect to be listed here.

But it should give you a brief overview of the experience I gained over many years of professional work as a solution architect, and from the view of a developer or lead developer.

Hope to see you again in the next chapter!

Photos on Unsplash