Architecture Articles

Configuration Management – Just Do It!

Configuration Management, as applied in DevOps, is the practice of using tools to manage the configuration of our technical architecture.  Put simply, we document the desired state of one or more servers in a machine-readable form, and then use a configuration management tool (e.g. Chef, Puppet, Salt, or Ansible) to setup the real items to match the configuration.

Why?  As with many things, you might think “I barely have time to setup this server manually, never mind write a script for it”.  But the reality is, in today’s world, we’re probably going to have to do the same setup multiple times.  In enterprise environments, the software engineering process will require deployment to several environments (development, integration test, user acceptance test, performance test, then finally production).  It’s critical that all these environments are identical (so far as is practical).  This is a key tenet of DevOps operating practices – we can’t apply learnings from one environment to others if the environments are different.  Even in a simpler environment, you’re probably going to replace your servers in a fairly short time frame.

Once upon a time, we used to buy server hardware and nurse it along for years.  Nowadays, hardware and system software ends up obsolete in a matter of months, not years.  If you’ve done your CM work properly, it’s faster to deploy to a fresh OS image than to patch an existing image.  And if you’ve embraced virtualization or a cloud environment, you’ll find it’s easier to replace a server than to troubleshoot it.

There’s another advantage to Configuration Management:  The system state is documented and version controlled.  There’s no need to do archaeological work to find out what your technical architecture has evolved to – you just look at the configuration scripts.

So here’s your challenge for the next year: Stop managing your servers by hand.  Setup an open-source Configuration Management system and create a configuration repository (I’m partial to Ansible.  See for some tips to get started).  Every time you find yourself ssh-ing or logging in to a server, stop yourself and create a playbook, recipe, or run-list in your CM repository.   Make it a habit to use manual tools only to examine the server state, not to change anything.  Run your servers the way developers write code:  If it isn’t in version control, it didn’t happen!

For that matter, do the same thing on your laptop or workstation.  You’ll soon find that you’re much less stressed about maintaining your configuration or upgrading your hardware.

No Comments

MuleSoft Summit 2015 in Toronto

On July 16, I attended a one-day MuleSoft Summit in Toronto. In a nutshell, Mule is trying to add more API management capabilities to their platform. They are not alone in this rather crowded space with IBM, Mashery (the “inventor” of API Management), WSO2, et al, helping companies make their internal APIs and other information assets publicly available. Usually, this is done via RESTful endpoints (deployed in a cloud or on–premise) for consumption by AJAX-wired clients.
Read the rest of this entry »

No Comments

Architects – do you know if your team members are embracing your work?

Architects can generate volumes of documentation and models, but who reads them? They can even model these things in tools, but does this ensure the architecture is followed?

My experience is in any project – large or small – you can usually tell if the architecture has become a shared vision by looking at the members’ work spaces to see what they have pinned to the walls. Or the one-pagers they bring to meetings. People will post helpful things in their cube:

• A picture of the reference model/conceptual model – a picture of the shared vision
• A picture showing a typical collaboration of the solution components:

Typical Solution Component Collaboration

• A picture showing the architecture dependencies between the major subsystems which teams are usually formed around.

Solution Component Build Dependencies

Solution Component Build Dependencies

• A picture (i.e. collaboration diagram) depicting a key design pattern meaningful to their work
• A checklist of items to consider before submitting code for the nightly build or sprint
• A high-level diagram that illustrates the flow of artifacts to coordinate a sprint/increment

Configuration Management Centric Development Flow

Configuration Management Centric Development Flow

• A high-level diagram that illustrates how all the key processes relate to each other

Enterprise Modeling to Sprint and Release

Enterprise Modeling to Sprint and Release

If isn’t pinned to their cube it is handy and people will bring them to meetings.

Solution implementation is a fluid thing and these diagrams must evolve. This is performed by a regular architecture/team lead “stand up” meeting. Not stand-up because people have to stand up, but because people are there to discuss items that matter. They are busy and focused on being productive. All subsystem/stream leads are focused on sharing critical items and gaining consensus that will move their team forward.

The facilitator is the lead architect – not because they know more, but because they are a good facilitator and believes a better architecture is made from ensuring the best ideas are leveraged no matter the source. The lead architect (or technical manager or scrum master) does have to have a breadth of knowledge to be able to understand all the topics discussed and ask questions to help the team come to a decision.
The meeting doesn’t talk about status, schedule, or resources. It focuses on the product and topics like:
• Points of integration
• Dependencies
• Alternatives and recommendations to leverage the experience of others
• Shared services
• Recommended patterns, practices, and standards
• Technical issues to be researched and reported on at the next meeting

The meeting can be managed by using many different techniques:
1. When items come up that involve a subset of people, quickly identify the stakeholders and assign a working group to bring a recommendation back
2. If not enough information is available, assign someone to research the additional information
3. If a knowledge gap is apparent, the action item may be for the lead architect to schedule training
4. If the problem appears to be a vendor product issue, the technical person responsible for that vendor relationship takes the action item

Whether you call the facilitator the lead architect, technical manager, scrum master, or servant leader, they are the “glue” of the product and process for the design and build teams.
At the end of the productive meeting, the lead will update:
• The Action Item Log
• The Decision Log
• The Risk Log

Also the lead architect will reflect on additional action items that may be helpful to the team:
• One-on-one discussions to further refine the problem or educate members
• Additional formal training
• Engaging management with the vendor to gain better response time
• Additional tools (e.g. automation scripts) to help the team
• New or revised patterns
• Demos from a team that will help solidify the vision and encourage the team
• Informal sessions from a team member that performs really well on a technique that other people are struggling with

This person, the “glue” is many times invisible and behind the scenes helping the team leads/scrum masters of a team to be successful. They work with management behind the scenes to buffer the team from “necessary but evil” overhead. They encourage team leads when they are frustrated because they have been in that situation before and can empathize. The invisible super glue 🙂

1 Comment

What is Enterprise Architecture and How Can it Give My Business Competitive Advantage?

When we teach Enterprise Architecture, we always ask our students, “What problems do you have that make you want to do Enterprise Architecture?”

The answers tend to have a few themes…

“We have a lot of systems that don’t talk to each other.”

“Our applications have grown to the point that we can’t maintain them.”

“It seems really hard to get new systems done.”

Enterprise Architecture (EA) means different things to different people.  It can mean a description of the IT systems that support a business, including their interactions and plans for long-term evolution.  It can describe the organizational group responsible for developing that architecture.

Read the rest of this entry »

1 Comment

The Journey of a Thousand Miles in Architecture Education Begins with One Step – TOGAF 9 training

Reason #1 – The field of architecture is broad and deep

  1. There are multiple architecture methods (Zachman, TOGAF, FEAF, DoDAF, MoDAF, TRAK, etc.)
  2. There are multiple modeling standards (UML, Archimate, SysML, etc.)
  3. There are multiple architecture styles (SOA, MDM, MOM, EAI, etc.)
  4. There are various architecture modeling tools (Sparx EA, Magic Draw, various Rational tools, Troux, etc.)

Reason #2 – TOGAF offers the most comprehensive approach as a starting point

  1. Offers a comprehensive method – The Architecture Development Methodology (ADM)
  2. Offers a slew of techniques (gap analysis, business scenarios, migration planning, stakeholder management, capability-based planning, and etc.) and concrete artifacts (catalogs, matrices, and diagrams)
  3. Covers the four primary architecture domains (business, data, application, and technology) as well as supporting sub-domains (security and interoperability)
  4. Provides two reference models (TRM and III-RM)
  5. Defines a generic governance framework
  6. Defines a capability framework to address the skills, roles, responsibilities, and team structure side of things
  7. Defines a content framework with an underlying meta-model to support relationships and linkages across architectural model elements

Reason #3 – TOGAF Supports Customization

Read the rest of this entry »

No Comments

What is Service Oriented Architecture and Who In My Company Should Be Involved?


Today, organizations of all sizes are adopting Service Oriented Architecture (SOA) for delivery of critical enterprise services. In this post we will discuss what SOA is and who within the organization needs to be involved.

What is Service Oriented Architecture?

Service Oriented Architecture is an architectural style that exposes enterprise assets as services that can be configured and reused in business processes.SOA takes a process-centric view of the enterprise, viewing the enterprise as a collection of business processes. Three critical aspects of SOA are services, business processes and governance.
Read the rest of this entry »

No Comments