Agile provides the methodology enabling frequent and productive collaboration between key business stakeholders and IT. If you are responsible for key enterprise system initiatives in your business, whether on the business side or IT side, please continue reading as I discuss why using the agile methodology is not only smart, but required in our ever increasing need to strategize and embrace up-and-coming technologies to stay innovative, efficient, and competitive.
Since this is my High-Speed Blog, my goal of this post is to cover the important aspects in brief. Where applicable, links are provided to allow you to access additional details. I would like to give credit to Scott Ambler. I make references to his Agile Modeling site and find it invaluable. Let’s get started.
Overview
Businesses require enterprise systems to support their business processes. Of course, these processes are refined and grow as the business experiences growth. What we need is a methodology to keep both business processes and enterprise systems in parallel without hindering business growth.
The Fig. 1 depicts the growing number of features released as the system ages. Obviously, the enterprise system is not complete after the release of version 1, or version 2, or version n… It must evolve as the business evolves.
Now let’s take a quick look at complexity during the natural lifespan of enterprise software systems in Fig. 2.
It is very natural for enterprise systems to continue to grow in complexity, making it very difficult to extend and maintain.
Many times, enterprise systems must be replaced because they can no longer effectively support business growth. Specifically, the two major reasons for early retirement are:
- Enhancements and changes take too long
- Newer technologies offer promising features, and it becomes apparent that the current system is becoming a liability
Given the history of enterprise systems development, it is apparent that these systems take a lot of time to develop, and, many times, have trouble keeping up with new/changing business requirements. Today’s enterprise systems must have shorter development time lines and be more inherently extensible than in the past. Complexity must be strategically managed.
Agile organizations recognize the growing complexity issue and strategize by intentionally taking time, periodically, to tackle the complexity at the heart. Sometimes refactoring designs/frameworks, and sometimes replacing technologies as seen in Fig 3. This effectively changes the growing complexity curve into a saw tooth that periodically reduces complexity and ultimately extends the lifespan of the enterprise software system.
Of course, the smartest, most capable methodology is worthless if you don’t architect and design properly. Extensible and flexible software systems inherently possess architectures based on loosely-coupled systems, e.g., SOA, and make use of proven OO patterns and principles, such as the Open/Closed Principle. For more information, please see my posts on
- Support Your Future Critical Enterprise Software Initiatives, such as Integration with Popular Mobile Platforms, with a Well-Defined SOA
- Designing and Implementing the Open/Closed Principle
Keys to Success
- Change is inevitable, and good
- Have the right mindset & attitude
- Encourage active collaboration by core participants
- Demonstrate abilities (technology, platforms, etc…) early to provide an educated perspective the business & IT can use to draw inferences from that both target business goals and possibly extend those goals through strategy enlightenment (the light bulb turns on for the business now that it understands what technology can offer).
- Model a bit ahead
- Prioritize requirements
- Requirements may be reprioritized at any time
- Requirements can be removed at any time
Envision Initial Architecture
It is important to realize that collaboration with key business stakeholders occurs as early as the architecture defining process. IT typically reviews potential technologies and platforms, researching connectivity to other systems, development skills requirements, maintainability, extensibility, performance, scalability, concurrent user volume, and more.
Cut an initial vision and share it with both the business stakeholders and development team. Try to think 1, 2, and even 5 years out. This will flesh out the architecture.
The process looks like Fig. 4.
Building the Ideal Team
First, note that I did not say Development Team. In agile, a team of core stakeholders is essential to success. Do not underestimate the value in active collaboration among different business disciplines. Everyone’s role and participation is important. A list of ideal team members is as follows, and please keep in mind, these are included as a guideline and are subject to your project’s needs:
- IT Manager/Software Director or similar
- Software Architect
- Business and/or Systems Analyst
- Scrum Master (this can be an Analyst)
- Quality Assurance Analyst (typically the Lead)
- Business Leader from each discipline
- Active Business User from each business discipline (persons that will use the enterprise system to accomplish their work tasks)
- Lead/Sr. Developer
- UI Developer (as necessary)
- Other Sr./Mid/Jr. Developers (as necessary)
- Build Engineer (responsible for maintaining all deployment environments)
More Diagrams and Less Documentation
I believe that documentation is overrated. What is enough documentation? It is enough to get the point across to the intended audience. Business requirements are an obvious must. Technical requirements and user stories are beneficial as well as a business intelligence strategy. Written detailed design specs, however, are probably overkill. Not only are they time-consuming, but generally hard to follow. And definitely time-consuming to maintain. Actually, documentation is usually the last thing to get updated, and hard to trust as the system ages and multiple authors maintain it.
So what should we rely on to get our point across?
UML provides great tools for us in the form of diagrams and agile embraces UML. A plethora of diagrams are available in UML. I like to keep things simple, and commonly use only a subset of these. I find that adoption of change best happens in smaller, digestible pieces.
Here is my list of helpful, enlightening diagrams that provide general user interaction, architectural, creational, structural, and behavioral insights into developing enterprise systems. Please click the links for additional information.
- Use Cases Diagram
- UI Flow Diagram
- Technology Stack (High-Level Architecture) Diagram
- Component Diagram
- System Interaction Diagram (to show messaging and transaction flow between system components – basically a component diagram with more details)
- Domain Model (a.k.a., entity or data model diagram)
- Class Diagrams
- Activities Diagrams
- State Diagrams (for conveying state transition)
- Sequence Diagrams
- Deployment Diagrams
Remember, using agile, you use what makes sense. Regarding documentation, it is still necessary to produce documentation, such as Business Requirements, Technical Requirements, User Stories, and sometimes Technology White Papers (as it applies to the business). Do not do extra work for the sake of producing additional project artifacts.
Single Source Information
It is easy and common to decide that a system component, business process, use case, etc…, needs to be documented/diagrammed, and, in fact, a manager gives the green light to execute this task. However, without a proper understanding of the current project documentation/diagram artifacts, duplicate efforts can go unchecked. This can lead to the following:
- Decrease in consistency
- Increase in maintenance burden
- Increase in traceability burden
- Confusion and frustration by the team
When you are modeling you should always be asking the questions
- “Do I need to retain this information permanently?”,
- “If so, where is the best place to store this information?”, and
- “Is this information already captured elsewhere that I could simply reference?
A skilled systems analyst is a great gatekeeper of such project artifacts.
For more information, click here for Single Sourcing Information.
Sprints and Daily Scrums
Sprints provide focused, small development tracks that are typically from two to four weeks in length. They strategically break a large enterprise system development project into many smaller projects that are easier for teams to achieve and, hence, the business to see results. They also provide a committed goal that all stakeholders share, and everyone strives to achieve.
Daily scrums are daily stand-up meetings, no more than 15 minutes in length, that provide daily communication of statuses by all team members. In a typical scrum meeting, each member quickly discusses his or her
- achievements made yesterday,
- what he or she plans to achieve today, and
- any work impediments
This information is useful in keeping the team on track to successfully complete the sprint. A larger definition of scrum is found here.
Get It Out There: Provide Multiple Environments for Multiple Audiences
Things move fast in an agile environment. Providing just one or two functioning environments is not enough. Our core audiences all require an environment that they have ownership over, and can use for their particular needs. The following groups commonly comprise our audiences:
- QA
- Demo
- Training
- Production (formal release)
Deployment Strategy: Focused and Frequent
Focusing on frequent deployments allow users to get familiar with the system early. I did not point it out at the time, but refer back to both Fig. 2 and Fig. 3. Notice how the version releases are more frequent in Fig. 3 using agile. This has many advantages including, but not limited, to the following:
- Testing and refining user experience
- Testing and refining features
- Training users
- Presenting demos
- Frequently delivering needed features to the business
Typically, delivering to these audiences in a staggered order provides the best use of time. Remember, in enterprise systems, we don’t simply call it code complete, deploy to QA, fix a few bugs, regression test, and deploy to production. There’s more that happens between “A” and “Z”, the hand off from IT to the business users.
Upon code complete, QA receives the deployment in their own environment. A thorough testing of use cases, user experience, performance benchmarking, and more take place. Bugs and or tickets are written on issues and submitted to IT for fixing. This path between QA and IT will be very iterative until a decision is made to deploy to the Training and Demo environments. A decision can be made to deliver even with known issues, if the issues do not adversely affect training and demos. However, the issues are still solved by IT.
To track the source code, a version control system is used. Branching and merging of source code within the version control system is used to effectively manage these deployments.
Once IT, QA, and business stakeholders are satisfied, a final source code version is marked, or tagged, in version control. This version is finally deployed to the production environment.
Conclusion
Each organization must learn, practice, and refine how they put the agile concepts into action. Different industries will have different needs, whether healthcare, education, insurance, online retailer, bookstore, grocery chain, etc… Keep things focused and as simple as possible, and, most of all, get active collaboration by all key stakeholders.
I truly believe by incorporating the agile methodology into Enterprise System Development, businesses can spend less time worrying about their Enterprise System(s), and more time creating innovative products and services with the knowledge that their Enterprise Development is on solid footing.
I hope this was helpful. I’m Brian Buikema. See you next time!




