Agility in Requirements and Design

Agility in Requirements and Design

Many organizations rely on heavy documentation for requirements, architecture, testing, and implementation. Often times these documents go largely unread, forgotten and exist for the sole purpose of creating a legally binding document between the IT department or consultant, and the business or organization. Iterative development, and defining solutions with close involvement with the customer is key to the success of an Agile project.

In a way, a Requirements document may be used by the business as a means to state the contractor or IT department did not exactly do everything which was written in the document. My question to that is, so why do we have a requirements document? Is it a deterrence in case an IT Department does not do what they were supposed to do? These documents go largely unread, and the development team is often confused by what is stated in the requirements, leading to longer development time and time to market.

Recently, I’ve had the chance to work with simulation software with several colleagues. Many software applications today are web applications, built using a standard n-tier architecture. At the top of the tier is the presentation layer (what a user sees), in the middle is the application layer (when a user clicks an element in the presentation tier, what it “does” is defined in the application layer), and the bottom is the Data Tier (stores all interactions, information, and interacts with the application layer).

The user (and often times the customer) only sees the presentation layer. So, why not build that first? Your business customer wants to see a solution, help mold it, shape it, and see what it will look like. The business logic is often times already defined; it is the way the user interacts with the system which will involve the customer into the design of the solution.

Many simulation tools and Integrated Development Environments (IDEs) provide the ability to build out a custom user interface with some functionality. It can be built on the fly, quickly, and demonstrated to the customer. A development team can then take software developed in the simulation environment, and build out functionality and code behind the presentation code. This increases agility, providing the customer with a functional prototype which can be quickly built with a level of functionality behind it. Developers can take it, and understanding how the presentation tier works define the application and data tiers.

The requirements document is key to documenting all requirements, but often leads to a large, unusable document for the development team. Creating software within a simulation environment provides a method for IT departments to quickly deliver a working prototype and functional software. Ultimately, this deters the customer’s notions “I’ll know it when I see it.”  Forward to Agile!

Enterprise Architecture: After the Executive Buy Off

Enterprise Architecture: After the Executive Buy Off

What is it that an Enterprise Architect (EA) does? Why do we need EA’s? After these questions are presented, answered, elaborated, and elaborated some more, hopefully the executives will give in and say ‘go do your EA’.  Now, what is the first step?

The importance of leaders embracing and understanding EA cannot be underestimated; aligning business objectives with technology allows organizations to make better use of their existing technology, providing a clear strategic, technology driven path going forward.

Technology enables the achievement of business objectives, a key statement applicable to the first steps in establishing a true Enterprise Architecture. Isolating the business goals and functions from the technology currently utilized within the organization is key in developing an enterprise architecture. A strong understanding of business requirements and objectives is required.

Discovering business objectives, drivers, and goals may be a complicated task when there is limited technology or a small, mostly operational / help desk Information Technology (IT) department. There are several techniques, both technical and non-technical an EA may utilize in obtaining and understanding business objectives. These skills and techniques are often used by Business Analysts today.

  • Interviews: Interviewing key managers (CIO, CEO, CFO, CTO), leaders, and stakeholders provides a wealth of information on business objectives or goals.
  • Company Mission Statements / Documentation: Review organizational documentation which may be found internally or externally. Different branches of a large corporation may be responsible for different business objectives or goals.
  • OMB Guidance and Definitions: For Federal Enterprise Architecture, the Office of Management and Budget (OMB) provides guidance and definitions on various objectives and goals Federal Agencies posses.

Another, however lower level aspect which must be understood while establishing an Enterprise Architecture: the business processes undertaken to meet the business objectives and goals. Business Process Modeling (BPM) is an excellent technique to create Business Process Diagrams (BPD). These diagrams display a step-by-step process for achieving a particular business goal or objective. BPM’s are often completed using the Unified Modeling Language (UML) based Business Process Modeling Notation (BPMN) depicting flow elements, swim lanes, and artifacts utilized and completed throughout the execution of the business process.

From these, a Business Reference Model (BRM) may be created. The BRM is one of the most important artifacts in establishing an Enterprise Architecture within an organization. The BRM concentrates on both the functional and organizational aspects of the business and helps establish the Business Architecture.

Having a clear understanding of the Business Goals and objectives is important to establishing an excellent Enterprise Architecture, and eventually aligning business goals with Information technology. The technology supporting the business is then defined in the Technical Reference Model (TRM), Application Architecture, and Data Architecture.

What are your first steps to establishing an Enterprise Architecture?