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

Application Architecture, Defined

As part of our initiation of the IT Architecture Journal, we've been trying to help define the landscape - we're continuing that trend today with an introduction to Application Architecture. These definitions are being provided as a foundation - both for IT Architecture education in general but also as part of our larger goal to help harmonize industry terminology and expectations regarding IT Architecture. And of course these articles also serve as a foundation for us as we delve into more detailed or specific topics later. Like so many other aspects of Architecture - there is quite a lot of overlap and complexity connected to Application Architecture.

The definitions we provide here are not meant to be mere academic representations of some well understood a priori knowledge, but rather are based on experience from many years of architecture practice. The goal here is to provide the most pragmatic explanations possible - and to clearly link what might otherwise appear to be conflicting concepts. In other words, we are attempting to demystify IT Architecture.

First, let us address the overlapping or conflicting terms. Application Architecture is often referred to as System Architecture, Systems Engineering or even Software Architecture or Design (or even Software Engineering). All of these terms are roughly analogous and can fit neatly within the scope of Solution Architecture (which is itself a subset of IT Architecture), yet there are aspects of Application Architecture practice which are stretching the bounds of what it encompasses. Even within some of these other terms there lies deeper hierarchies of sub-terms; for example within Software Engineering we'd likely find both Object Oriented Design and GoF (Gang of Four) Pattern Design. When we begin to discuss SOA (Services Oriented Architecture) and SAAS (Software as a Service) then things will get even more complicated as we will see.

Application Architecture would be focused mostly within the Business Tier of this view

Application Architecture, Defined
Application Architecture is the set of design activities and artifacts associated with the production or management of solution logic. Solution logic is the set of business rules and functions that support key processes or workflows associated with any given organization. While Application Architecture requires and / or manipulates data and sits atop an infrastructure it often viewed separately from those elements in organizations where infrastructure as a service or data management organizations are in place. There are usually clear delineations regarding where application responsibility ends and data or infrastructure etc. begin.

Application Architecture generally follows systems and software design guidelines or expectations; so an Application Architect would likely use UML to create Class diagrams to help model data for their application, whereas a Data Architecture would likely use an ERD or Dimensional to do something similar (even though both are working with the same data in that context).

Application Architecture is represented in most of the major EA Frameworks; in TOGAF and FEAF it is referred to as Application Architecture, in Zachman it Systems. In DODAF it is roughly equivalent to Systems and Services Views.

Skills Required
To work as an Application Architect, you'll need the following skills:

• The ability to design and problem solve.
• The ability to use UML notation to capture standard designs.
• The ability to apply standard patterns or create / define your own.
• An understanding of the underlying technologies involved. Object Oriented design in Java is generally quite a bit different than scripting with JavaScript and Perl in a LAMP stack. 
• The ability to understand and harness / exploit an Application Development Lifecycle and associated tools - this is referred to in industry as Application Lifecycle Management (ALM). 
• The ability to translate business needs into business logic and to define integration of that logic within the system environments available. 

A Note about SOA
So, what makes SOA a game-changer for Application Architecture? Basically it has to do with implied integration across other "tiers" of the overall Solution Architecture. SOA brings with it a sort of mega-pattern for design that includes expectations for data access and infrastructure exploitation and thus it is sometimes hard to abstract these non-application elements of the solution. While it's easy enough to abstract all this from the developers (you simply give them the guidance and the self-service development environments) for the architect it's not so simple. We'll be talking about this more soon...

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More