Lifecycle Management, Defined

Like many other aspects of Information Technology over the past 15 to 20 years, Lifecycle Management has evolved quite a bit. In fact, it didn't generally even get referred to as "Lifecycle Management" until about ten years ago. It (both the term and the practice) has become more expansive in nature as time has passed. This is an interesting not just due to the evolution which has occurred to the surrounding practice, it is also the one area in IT where technology and business / management comes closest to being blended into one concern.

Lifecycle Management is also the reason that IT Architecture exists the way it does today - without the driving force of various governance processes and mandates, IT Architecture would have likely never quite crossed the threshold from systems or software engineering and design. We'll return to that in a minute.

So time for definitions - and in this case - a hierarchy.

Lifecycle Management, DefinedLifecycle Management is the practice of coordinating all the related activities for any given selection of IT capability (within or across organizations). There is generally a hierarchy for these activities which falls roughly into the following structure; Portfolio, Program, Project. Generally at the Portfolio level, the capability management spans many systems whereas there may be multiple Projects supporting just one piece of software or one system. In an optimal situation, all Lifecycles should be unified based upon shared methodology, principles, goals and supporting tools. 

Many people have long considered Lifecycle Management to be the province of the manager. However, nothing could be further from the truth. For Lifecycle Management to function as intended there has to be a partnership between management and technology resources. This partnering usually occurs on the tech side through the role of IT Architect.

This view is a more traditional enterprise-focused view (mainly waterfall in nature) 

Why Lifecycle Management isn't just about Management
Let's go over a few things that must have technology input to succeed:

1. System (and project) Scope - While there may be a number of specific expectations from business, the most successful systems (and projects) are those in which the tech side helps to define the boundaries of what can realistically be done. This manifests itself at the highest level in portfolio roadmaps and at lower levels through statements of objectives or similar scope documents for projects (which then get passed through governance processes for approval). 
2. Project Estimation - This is a much more complex process than many realize. Good project estimation requires a precise understanding of the complexity of the technical tasks involved. Whether you're talking about building J2EE-based APIs or deploying a WCMS, the tech experts who have been there / done that are invaluable in helping to define a realistic project estimate. Since much of IT is measured based upon estimated cost versus actual expense - this area is disproportionately important. 
3. Risk Assessments - Sometimes this includes Architecture Assessments, other times it is more of a technology strategy type exercise.
4. Technology Selection - Should we Build or Buy, or if we're going to buy, how do we choose? These are the typical questions that get asked, but who can really answer them? The IT Architect, of course - its part of their job description.
5. Solution Decomposition - This is related to project estimation but more detailed. Generally, somewhere within a planning process, there is a preliminary design exercise which goes as far as determining how best to 'break up' elements of the intended solution into digestible pieces. This also involves prioritization - understanding which parts have to come before or follow others due to various technical dependencies or constraints. 
6. Project Oversight - This is a big topic, one we will dedicate other posts to, but for now we'll just introduce it. IT Architects often play a semi-leadership role within individual projects (as a project or solution architect). This is so technical issues can be tracked, managed and mitigated with continuity across all phases of the individual lifecycle. 
7. Enterprise Integration - This is without a doubt the hardest part of the overall set of potential Lifecycle Management related activities. Now, many think of Enterprise Integration as a purely code focused or networking relating topic - believe me it's not. Enterprise Integration is in reality the intersection of potentially overlapping systems, data and expectations. The most important aspect of Enterprise Integration is inter-operability design  (which comes in many, many forms). It's a study in complexity and not for the faint of heart. 

Let's step back for a moment and explore Lifecycle Management from a different angle. In previous posts we've been talking about methodology a bit; Agile, Waterfall and so on, but what does it all mean? The short answer goes something like this:

An IT methodology quantifies the workflow or lifecycle steps necessary to provide consistent support for system development and management. Most lifecycles share the same common elements; a planning phase, design phase, build phase and implementation phase. And yes even Agile has all of these. Within the common framework, there is a massive amount of variation. So, if you ever had to work with Carnegie Mellon's CMMi (waterfall spiral methodology) and then were put on a Scrum project (Agile variant) it would be like moving from Iowa to Italy - a culture shock to be sure. 

In today's terminology, you often hear the term Application Lifecycle Management (ALM) used - it is essentially the same thing as Software Development Lifecycle (SDLC) except perhaps that today an ALM can encompass both Waterfall and Agile whereas before SDLC was more Waterfall focused. So what are Waterfall and Agile, anyway? 

Waterfall - this refers to both purely linear and 'linear iterative' development methodologies, wherein requirements are more fully defined up front and allocated to segments in a somewhat sequential manner. In some cases, code is completed and tested in iterations - other times no capability is delivered until the very end (traditional waterfall).

Agile - Up front design is minimal, few if any requirements are formally development. The focus is the production of working capability with each (very short) iteration. Design in this model becomes iterative in that core assumptions can be readdressed and correct "in flight" (which is why up front requirements become redundant or unnecessary). 

We will be talking a lot more about 'Agile' and 'Waterfall' as we progress on the blog. 

Lifecycle Management has evolved from a set of competing software development methodologies to become a potentially all encompassing set of technology management processes for the enterprise. And it will continue to evolve with the IT Architect maintaining a key role for some time to come.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Aligning Lifecycle Methodologies - Part 1

In a previous post, I contended that requirements are still an important part of most enterprise environments, even those that might be using Agile lifecycle methodologies. However, I didn't specify exactly how those requirements should be captured — or even what constitutes a requirement. This is an important question when determining how to align multiple lifecycle approaches within one organization (the need for which is much more common than most people realize)

This question encompasses two major lifecycle approaches; Agile and Waterfall methodology. Many organizations feel that User Stories (Agile) are sufficient to build both code and project structures around them. Is it out of the question to consider that Use Cases might be used within an Agile approach?

Before answering that, let’s take a look at User Stories, Use Cases and Requirements in context again:

• A User Story can be thought of as a high level or conceptual scenario, or perhaps just a problem. An example might something like this: A user needs to be able to save a report into multiple file formats for downloading, including both .pdf and .xls. Even though we’ve described two different formats, it still represents the same scenario or problem.
• A Use Case, on the other hand, can be considered a functional requirement. The difference between a functional requirement and technical one is the level of detail the document includes about how specific actions are carried out. For example, a use case would capture the process flow, or steps involved in generating the report and the expected outcomes or alternatives. This helps to build test cases later on. A use case is slightly more structured and detailed and is generally written by someone IT or in combination with the IT group. That way, some of the technical expectations are captured. In other words, the use case describes not just behavior, but how that behavior is achieved.
• A Requirement in this context refers to a technical requirement. This is entirely specific to the elements needed to develop and/or deploy the capabilities described in the previous two documents. It allows us to formalize performance constraints, data elements and other pertinent technical details. This is especially important in environments where EA, service or data governance paradigms are in place. If written properly, requirements can then serve as system documentation.

Mapping across lifecycle approaches begins with requirements (however they're captured)

While many organizations practicing Agile bypass requirements, they may in fact still capture the same information after the fact if they actually document their deployed solutions (after the fact). When you’re considering whether or how to employ user stories and use cases, keep these points in mind:

• They are not the same thing.
• The user story ought to come first.
• The use case ought to be derived from the user story.
• Any requirements managed from this process should be embedded within, or otherwise traceable to, a specific use case and user story.
• User stories could be considered either scenarios, high-level processes or problems.
• Every organization approaches this process somewhat differently. For example, in a less Agile environment, a number of other architecture artifacts could be added to the illustration above:
• At the user story level, many people like to capture a data-flow diagram or a context diagram.
• At the use case level, many folks like to add a UML sequence diagram and conceptual data model.
• At the requirement level, many UML diagrams are often added including activity models, state models, component diagrams or deployment diagrams.
• If a formal EA framework is being applied, those UML or ERD diagrams are often replaced or folded into EA Framework views/artifacts.

Getting back to the original question — should use cases be used with Agile lifecycle management? — my recommendation is yes. Here’s why and how.

Why to Do It

1. It ensures some level of systems engineering is included in the Agile design process.
2. It helps to define the tasks associated with each user story and doesn’t add that much extra effort - it also doesn’t require a use case diagram (which in most cases doesn’t convey that much meaning anyway).
3. It ensures that both IT and business stakeholders capture their expectations in formats tailored to their roles and needs.

How to Do It

• Define your use case template and what it must convey.
• Determine whether user stories require more than one use case. It happens occasionally, although in most situations user stories should be in a 1-1 ratio.
• Ensure that someone from IT helps with, or provides much of the detail, in the use case.
• Ensure that use case development is aligned with both the quality and testing paradigms. This is especially important if no requirements are captured.

The majority of Agile development environments are fairly flexible in regards to storing of related attachments, so the biggest impact to employing use cases along with user stories is in the design and development process. This is the first step towards aligning lifecycle methodologies; we will examine this further in several upcoming posts.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Business Architecture, Defined

There are a number of disciplines within IT Architecture that tend to overlap, part of this is because the definitions haven't achieved industry wide status (for example, various EA Frameworks define similar functions with different terms and they also often use the same terms differently). Part of the problem in this case though, has to do with the relative ambiguity regarding how and where IT Technology and Business drivers can or should mix. There is also some confusion in relation to where Business Analysis ends (as a practice) and where Business Architecture begins. We will help to answer some of these questions in this post.

Business Architecture has many potential components and drivers

First, let's attempt to apply a standard definition to the practice area:

Business Architecture - This represents the entire set of design activities associated with translating business needs and expectations into technical solutions. Those design activities include the following typical tasks and / or artifacts: Context Maps, Concept Mapping, Process Engineering, Capability Maps, Business Rule Definition, Conceptual Data Modeling, Domain Modeling, Class Definition, Object Definition and Business Glossaries. This list is not exhaustive but it does highlight that Business Architecture includes both analysis and design. It also shows that there are clear intersections with data and application (system) architecture. Business Architecture tends to be the first area of design focus within the overall lifecycle of any given solution or set of solutions.   

So, in reality there are many people who work as Business Analysts that in fact perform Architecture tasks. On the flip side, many architects are asked to define and manage requirements or otherwise work side by side with business stakeholders and analysts to help better understand workflows and data contexts. The lines here are indeed fuzzy as the type of architect asked to do all of this may be referred to variously as a Solution Architect, Data Architect, Project Architect or perhaps even something else. Use of the term "Business Architect" is still relatively uncommon. The reason for this is most likely that many organizations want Architects who can perform those upfront Business design activities but also follow that with more specific types of solution design tasks and artifacts.

Business Architects often use EA tools to perform these types of activities; products like Mega or Troux allow Business Architecture to managed in the context of TOGAF driven enterprise. Other tools can be used to manage governance, application policies, business rules and other types of design artifacts.

Another important aspect of the role of Business Architects is their focus on Lifecycle Management. Now, we will address Lifecycle Management in more detail in another upcoming post, but the key elements involved are Governance and Portfolio coordination. So, Business Architects also often help to oversee Governance processes, help develop Business Cases, estimate project costs and schedules and otherwise support portfolio planning processes.

When we view all of this in the larger context of IT Architecture, it is worth considering the larger question whether all architects ought to have some experience working on the "business side" of solutions in order to better understand why some projects fail and how to better align business goals with IT reality. Another facet of this topic is the notion of what an Architecture Manager does. That is a role that isn't necessarily associated with Business Architecture per se but nevertheless includes quite a number of similar tasks and artifacts. Any IT Architecture manager (regardless of the type of architecture being performed) must be able to manage project planning, cost estimation and other types of team collaboration activities.

We will examine many of the terms and concepts introduced here in greater depth in upcoming posts.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Why Requirements Still Matter

IT Architects deal requirements in many contexts; there are requirements associated with the management of architecture itself, the requirements of the enterprise which drive an entire portfolio and the more specific detailed requirements associated with solution design. Today, we're going to examine the requirements in the context of Solution Architecture - a domain where Agile is sometimes interpreted as a "requirements-free zone."

These days, requirements management is often misunderstood or under-appreciated in IT. Many people have used migration to Agile methodologies as an excuse to discard requirements or rethink how they’re used to support most projects.

In the overall lifecycle of lifecycles, requirements becomes critical in establishing traceability

One of the key tenets of Agile application development is not to over-think technical requirements in advance. The premise is that it’s usually impossible to accurately predict the details, which would invariably lead to costly rework after the fact—as opposed to an Agile approach of incremental refinement.

So who’s right? Do Agile advocates make a convincing case that a too-precise definition of requirements is counterproductive, or does the more traditional view of requirements management make more sense? Before we answer that question, let’s review several pertinent factors:

• Not all IT projects involve coding (for example, software development).
• Even Agile methodology includes some level of requirements definition.
• Many, if not most, organizations track “functional” level business requirements, a task usually managed by business analysts.
• The majority of people who collect and manage requirements don’t follow a specific methodology, since it’s often considered less important than the follow-on development or implementation activities. What’s more, most people don’t realize that requirements management is a collaborative activity.

Maybe both camps are wrong, or perhaps both approaches suffer from a similar flaw. Traditional requirements management and Agile requirements represent two ends of a spectrum—and each assumes the other end is ineffective.

Common Ground

As in most things, the truth lies somewhere in between. Not all requirements are the same, so they shouldn’t all be managed the same way. Either camp could go wrong in this area. Also, the main reason that requirements management has come under criticism isn’t that defining solutions up front is intrinsically wrong, it’s that defining solutions out of context is.

Followers of both traditional Waterfall and Agile techniques can fail to define solutions in context. The difference is that with Agile, the flawed results are more likely to be noticed early. Context can be lost when a team develops requirements without:

• End-user input
• Stakeholder input
• Use cases and test cases
• Mechanisms for validation and incremental development
• Integration of business and technical requirements processes.

It’s worth pointing out that the controversy over whether requirements management is a worthwhile practice hasn’t led to widespread insight into how it can be corrected. Instead, it has led to sporadic use of requirements or a complete disregard for them. Meanwhile, even with Agile, the success rates of IT projects haven’t improved all that much.

The Best of Both Worlds

Requirements management is the most logical place to integrate business and technical processes and teams. Instead of moving from one either/or philosophy to another, we should take the best elements of each camp and create a better approach.

Far from abandoning requirements as a central part of every project, it’s time to start advocating their use in all projects. Here’s why: Requirements are the foundation of all good design and architecture, all portfolio and project management, and all project or solution collaboration. If compiled properly, they capture vision and thinking from a diverse spectrum of team members and document the solution as it’s progressing.

As we said, not all projects need to apply requirements the same way. Conditional requirement approaches might be applied to these project categories:

• Pure Development: Little or no code reuse. This might involve a more Agile approach, including more experimentation and more test-driven or scenario-driven requirements.
• Commodity Development: Significant use of existing libraries or software packages. This might focus more on integration and performance requirements. For example, an existing knowledge base may support more detailed technical requirements.
• User Interface-Driven Solutions: Much more focused on event-driven expectations and extensive user stories.

Requirements don’t have to predict all aspects of a solution, and they can be corrected or updated as the solution emerges. They can easily become evolutionary in nature. The bottom line is, don’t skip them. Compiling them now can save you a lot of trouble later.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

The Practice of Architecture Assessments

One of the most common tasks that an IT Architect will be asked to do across the course of their career is the Architecture Assessment. It is more common to conduct these if one is working as a consultant rather than an architect on an internal team, but even in those instances it is likely that an IT Architect will have to perform at least a few of these.

In the context of a larger solution lifecycle, the Architecture Assessment tends to occur most often in the initial phases (Discover, Analyse etc.), however assessments can occur at any point within the lifecycle as part of a problem-solving exercise or can occur entirely outside of the scope of any given solutions lifecycle. Assessments are disproportionately (in relation to time / dollars invested) important activities for a number of reasons:

1. It represents a dedicated effort to validate or discount core assumptions
2. It provides a mechanism for honest feedback (w/o fear of retribution)
3. It allows for rapid problem-solving and design exercises in environments where that might not otherwise occur.

Assessments are not a clear part of any particular EA Framework methodology (they may be implied in some sense), however that doesn't mean that they should be conducted in a haphazard manner. Assessments should be planned, estimated and designed in order to provide clear outcomes (be they recommendations, design deliverables or both).

Problem Space analysis is one of the techniques used with assessments - it can apply
both to the business and technical aspects of a project

An Architecture Assessment is also different than other traditional Architecture activities in that the expectation is generally that third-party personnel are more likely to perform them. The reasons for this include the following:

1. Assessments are one of the key tools involved in IT oversight activities (sometimes referred to as Independent Validation and Verification or IV&V).
2. It is more likely that an accurate assessment can be obtained by architects / investigators without a vested interest in the project. 
3. The skillset of the person doing the assessment is critical - it needs to be an architect and not merely a technical or product expert. This is the only way to ensure that all options / alternatives are properly considered / assessed. 

So what exactly is an Architecture Assessment? A typical assessment tends to include the following categories of activity:

• Information Gathering  
• Design & Project Review
• Design & Project Recommendations

An assessment also typically includes one or more types of specific analysis as well:

• Analysis of Alternatives
• Root Cause Analysis
• What if Analysis
• Feasibility Analysis
• Trade off Analysis
• Problem Space Definition & Resolution 

One way to capture alternatives is through Decision Trees.

Perhaps the most important function that an Architecture Assessment can provide is a mechanism to challenge assumptions and combat complacency. One of the main reasons that IT projects fail today is because there is generally no incentive or expectation to raise issues or problems. Rather than being viewed as a healthy activity - identification of the problems is feared in itself and thus ensures even more pain later on when the issue finally surfaces (which they always do).

When compared to the cost of the rest of a typical IT project (and any potential loss or cost overruns associated with problems that aren't identified or managed in a timely fashion), a relatively brief assessment exercise is generally less than 1% of total cost yet could make the difference between success or failure...

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More