Software Development
Building a software system needs to be methodical to be successful, and it is just as much about the discussion and thought that happens between writing code as it is the code itself. Working through the process in a guided and structured manner ensures the outcome meets the expectation.
Software Development work is approached with two separate engagements: design and build.
Design
We begin with the design engagement where we detail out the functional and nonfunctional requirements of the system. This activity may include creating prototypes and mock-ups.
The deliverables of the design engagement are an initial design, functional and nonfunctional requirements documentation, a backlog of tasks, a project plan including a timeline, and a quote for the build engagement. Based on cost and time estimates we can work together to refine the scope in order to meet your needs, but there is no commitment to proceed at this point.
Build
The build engagement will first focus on operations, with deployment systems and automation being put in place to facilitate delivery. Development will continue iteratively for the purpose of constant review with you as the product owner. The activities for this phase will also be driven by the nature of the software, with formal reviews, UAT test cycles, and approvals being included based on need.
The primary output of the build engagement is the software system itself. However additional assets are included like documentation, playbooks, runbooks, and knowledge transfer sessions. Systems are not delivered in a bubble, so frequent check-ins and sponsorship meetings are expected, as well as any design meetings as new challenges arise.
AWS & Software Architecture
Cloud architectures can be complex, and it can be easy to introduce sprawl in an environment that often relies on distributed systems. Everything from governing your AWS Organization and designing a hybrid network, to application architectures and system integrations need to be planned to be maintainable.
Architecture and planning should be done at every layer in your AWS environment, some examples include:
- Account Structure
- Governance Strategy
- Network Topology
- Application Design
For accounts and systems already in place, we can perform an architecture review. This can be facilitated by an AWS Well-Architected Review (something I offer for free) or at a more technical level where we investigate in detail how a system is designed and configured. Either of these approaches will result in a document outlining the findings from the review and actions to improve the system.
DevOps Systems & Practices
Enabling better and faster delivery of software through DevOps is a great thing, but it's more than having a build server in place. Reviewing DevOps methodologies and practices can unearth better branching strategies, deployment tools, automations, and foundational ways of working.
DevOps is more than technologies and automation, it's practices and procedures that determine how your team is going to work and interact with the system they're building. Your organization's policies will help drive what needs to be enforced, and if you're looking to implement DevOps we will design the systems and procedures to meet those policies. Depending on the requirements this may be
- Security and Analysis Tooling
- Approvals and Gates
- Privilege Escalation Procedures
- Party Responsibilities
If your team is already doing DevOps, but encountering friction or issues, we can perform a review. Known areas of concern will be investigated in search of alternative designs, or by putting in place or improving procedures. As DevOps is more than the technologies used, these improvements must take into account external factors like existing business processes that limit or influence how something can be implemented. Together we will also review industry best practices, and how their inclusion could benefit the developers and the larger organization.
AWS FinOps
The ease at which you can get started using AWS is often at odds with what needs to be done to prepare for it. Lack of governance and cost controls can lead to out of control spending. Analysis of the organization's needs around cost controls and tracking allow for practices to be introduced to prevent unexpectedly high bills.
Reviewing an organization's Financial Operations in AWS begins outside of the cloud provider. An understanding of the information needed by the finance team will drive the reporting that is required to create it. Working backwards from there, the problems that the organization is facing in performing that reporting will be discussed and how those issues can be solved.
Teams may also be looking to perform cost-cutting for one or more of their workloads. We will sit down and discuss the monthly AWS bill for the system, and where the most impact can be made by looking at alternative designs, technologies, different licensing, or billing structures. It may be a combination of approaches that each yield a fraction of the required adjustments, but in total amount to large savings over the course of a year.