I work as a software architect in Washington, D.C. for a consulting company that serves federal government clients.
I have more than 20 years of software engineering experience, focusing since 2006 on software architecture and design. My experience includes work as an application architect, systems architect, and enterprise architect. I worked previously as a Java enterprise developer, writing code every day, and development team leader coaching junior developers and guiding software product delivery.
I can clearly communicate solutions and options to technical and business audiences, and have made public presentations to small groups and large conferences.
My approach to software engineering
Architecture is about making choices
Design choices balance competing needs. Some choices are more expensive than others to change when requirements change or when chosen solutions deliver insufficient value compared to their costs. When the cost to change is high, these architecturally significant choices call for more up-front analysis, proofs of concept, and clear understanding by the business and technology teams of the trade-offs being made.
Corollary: Document those choices
An important corollary to making decisions is: Decisions should be documented in a place they can be found.
When a business or its development team make important decisions, many factors weigh into why one choice was better than the others. If no one records what options were considered and why some were discarded, you will lose almost all value of those decisions due to fading memories and staff turnover. Why? Business requirements change. Technology evolves. With those changes, do the factors that weighed heavily toward decisions from 6 months ago still hold? If no one remembers why you made those critical choices, you’re back to Square One.
Architecture is about more than technology
Goals of business leadership, technical infrastructure, staff talent, and the availability and cost for training and consultants also factor into the design and effectiveness of sustainable architectures. For example, designing a microservices-based component architecture around Docker-ized containers deployed and managed with Kubernetes running on AWS could be a cost-effective solution that increases system maintainability, scalability, and availability. But if development teams lack skills with one or more of these technologies, is the business ready to invest in training, hiring consultants, and accepting a delay in delivery times as the development and operations teams come up to speed?
Agile complements architecture
A key benefit to using agile software development frameworks like Scrum and Kanban is they help uncover weaknesses in product design and architectural choices when the cost of making changes is at its lowest. Frequent and early deployments provide feedback on the viability of the technical architectural and the delivered business product to allow for quicker course corrections.
Since change is a fact of life in business and government, architects strive to design systems resilient to change. Strategies have evolved over the years to achieve resilience through component-based system designs that are highly cohesive (each part has a clear and distinct goal) loosely coupled (changes to one piece don’t impact unrelated pieces), and insulated from the outside world as much as possible (goals of the 12-factor app).
When systems are designed with clear boundaries between components, an agile development approach makes it safer to delay building or selecting every component of the system’s design at project start. As the project progresses, early software releases provide feedback on whether the chosen architecture is realistic and sustainable. Once design decisions are confirmed, other parts of the system can be selected, built out, or improved to meet the business’s needs.
Architectures must be comprehensible
Software architectures need to meet not only the non-functional requirements of a system – such as security, extensibility, availability, scalability, reliability – they also need to be understandable. A complex system design might solve complex business problems – at least temporarily. But if a solution is so complex that development teams don’t understand how to use and maintain it, the system unravels over time.
My experience has included designing solutions for many customers in different industries. These projects have provided opportunities to work across business units and external partners to understand business, financial, and regulatory requirements to create maintainable architectural solutions that meet stakeholders’ needs. This experience exposed me to several enterprise integration patterns, including web services using REST and SOAP, service components running in containers and cloud environments, microservices, asynchronous messaging systems, and shared data repositories.
Before turning to software architecture and design, I began my technology career as a web developer writing mostly Python and Perl deployed to Apache and Netscape servers. Since 1997, I began specializing in writing server-side Java components deployed to servers ranging from Apache Tomcat to WebLogic application servers, with some HTML and CSS as needed. Since 2004, my roles on projects have including leading development teams and working with business stakeholders to design a project’s overall solution.
My clients have included small and large private-sector companies in varied industries such as financial services, telecommunications, medical, and publishing. My recent work has been with U.S. civilian federal government agencies. I have met Public Trust background-check requirements for positions with the U.S. Department of Homeland Security and Federal Aviation Administration.
I live in Arlington with a beautiful view of the National Mall.