Sunday, December 15, 2013

Much has been made of the rift between agile developers and
IT architects, especially enterprise architects. Agile development has
turned the solution implementation world on its head, eschewing traditional architecture
and all other attempts to define things in advance. But the agile world
has evolved to the point where an architectural foundation is recognized as
necessary to implement agile on a large scale. Without architecture to
hold things together, you may well have a dozen agile teams moving in
completely divergent directions – rather than building a cohesive
product. But this doesn’t take us back to the world of big design up
front (BDUF) – architecture has to evolve as well. The key is to develop
the architecture in parallel with the agile development. Very much like
agile planning (where you create a high level plan, but only produce detailed
plans for the next increments – on a rolling basis), agile architecture starts
with a high level superstructure and detail is added as needed to support the
agile teams. Architecture decisions are pushed down and deferred until as
late as possible – so that refactoring is minimized when decisions are
modified.

In years past, architecture provided guidelines and
directives (often in the form of a reference architecture) and developers
either complied or they didn’t. Governance was applied after the fact –
certifying that a product was in compliance with the architecture (what a
surprise – it almost always was!). This, of course, led to architectural
anarchy and situations where organizations found that they had more than one of
everything (from platforms to coding styles) and many of some things (security
implementations, for example). This situation of maintaining multiple
platforms, redundant applications, and poorly documented code has led to the
high percentage of the IT budget being devoted to O&M, rather than new
development to address new business requirements.

So, what does this have to do with Architecture Owned Code
(AOC), you might ask? Well, at Everware-CBDI we have developed an
approach that supports agile development at scale. A component of the
approach takes all of the aspects that you want to have consistent across the
enterprise (such as deployment details, authentication, error handling,
auditing, data access, messaging,common
business APIs, etc.), creates models to capture these aspects and other design
patterns to be applied across the board, and generates the code for this “common
platform” that is provided to the development teams to build upon. While this
may include many low-level, utility services, it can also include access to
common business services and COTS APIs, such as for credit processing or
document management. Providing AOC automates governance and flips the
perception of architecture as an inhibitor of development to an enabler of
development. We have found that most development teams accept this
readily, because it lets them focus on solving the business problem rather
than being blocked by wrestling with the intricacies of the technical
platform. The AOC base grows and is refactored as required by parallel
agile architecture development teams.

The result is that development proceeds much faster because
the agile teams are ableto leverage this common
Enterprise-specific platform in much the same way they leverage provided APIs
in many current products, frameworks and languages. This
approach has many other benefits as well. For instance, the AOC is of
higher quality than hand-produced code, is consistent across all development
teams, and is able to more easily be modified or refactored. As a result,
the tendency of the code base to become more brittle as it grows is
fundamentally reduced. In addition, the refactoring exercises can be
essentially invisible to the agile developers – performed in an architecture
sprint, regenerated, and provided to the teams.

Architecture Owned Code has the potential to revolutionize
application development and fully enable agile development – at the enterprise
scale. To learn more about this new approach, please contact us.

Thursday, August 15, 2013

There seems to be considerable debate and confusion
surrounding the concept of estimation as applied in the agile world.Many appear to argue that estimation has no
meaning outside of the agile team, but sponsors and stakeholders need something
to base their decisions on and estimation is a key component of it.Perhaps we need to reengineer our definitions
and objectives at the higher level.

Typically, management wants to know how much X will cost and how long it will take to deliver before
making the investment; where X is some bundle of deployed functionality with an
associated business value.Not an unreasonable
request in a traditional environment where the application is the focus of attention.
The investment decision is how much greater is the value than the cost (the
ROI). Unfortunately, the estimation process is subject to considerable
uncertainty prior to the initial stages of architecture and design (the
uncertainty decreases with subsequent stages but does not reach zero until
completion and deployment – and then the estimation of the O&M stage
begins) – not a good foundation to base investment decisions on.

If we change our focus from applications to delivering
business capabilities and adopt an agile development process, the concept of
estimation changes as well.For example,
in traditional (stovepiped) development much of the development is actually
producing redundant functionality (in terms of delivering business and
technical capabilities), but this is obscured by the focus on the app. For example, all apps provide error handling
and audit logging as well as security (authentication and authorization) – how many
times have these been (re)developed?The
same applies to business-related capabilities. If we can take a broad view of the
capabilities required and identify sources for providing them, much of the development
may be avoided altogether.This, of
course, is the benefit from adopting a SOA approach.If we adopt an agile development methods and
establish an agile team with an associated cadence, the estimation question
should be something more like: how much
value can we produce in a given amount of time?Given that the team has a
cost for a given period of time (say, a year), and each delivered business
capability has a known value, we can still make investment decisions – what is
the net value produced from the investment cost.

Economics would say you should invest up to the point where
the marginal value derived equals the marginal cost of producing the next
increment of functionality (stories, capabilities).From this increments perspective, we should
expect the marginal value to be decreasing – because we are developing from the
product backlog in order of priority – so we build the highest valued items
first.Marginal cost should be flat or
decreasing as well – the cost of the team may be constant, but the cost of
producing the next item may go down as we build up and consume more (pre-existing)
shared services.

So, the investment decision changes from: is it worth
building this app? to is it worth funding
this agile development team for a year?This approach can be applied to determine how big the team should be and
even how many teams should we engage.The
value delivered should be maximized because the most valuable capabilities are
delivered first (along with the capabilities they are dependent on).This should hold even if the priorities
change because the product backlog embodies those priorities.

Monday, January 28, 2013

“There is more value created with overall
alignment than with local excellence.”–
-- Don Reinertsen

As I look back on over a decade of EA in the federal
government, I must say I am disappointed in the results so far.In my experience as an EA practitioner, I
have boiled down the role of EA to two areas:(1) Support decision-making by the business (mission) and IT leadership
– EA provides a repository of information about enterprise components and their
interrelationships in the form of a set of models that can be queried to gain
valuable insights; and (2) Provide guidance to IT to develop & deploy assets
that support the business.The role of
EA here is to help eliminate (or at least reduce) redundancy, inconsistency,
and inefficiency in IT and to promote alignment, sharing (reuse) and
interoperability across the enterprise.The first of these is an analytical role along the lines of business
intelligence (BI), using the EA repository as the knowledgebase.The second is a prescriptive role to evolve
the portfolio of IT assets in the strategic direction of the enterprise (based
on the EA Target Architecture).

Unfortunately, EA in practice seems to have come down
to two completely different things: (1) A compliance exercise to meet the
evaluation criteria of OMB and GAO.Never
mind the fact that both evaluation methods are intended to get agencies to
undertake “real” EA. Agencies seem
intent on doing as little as possible to score well on OMB and GAO assessments.
(2) A descriptive exercise that
typically focuses on the as-is situation.Although, “this is what we look like” does have some value, it is
limited and the exercise is very costly (ask DoD about the billion dollars
spent on the Business Systems Modernization program).But the primary shortcoming across many EA
programs is the lack of the intention to be prescriptive,
combined with the governance to make it happen.It is the second role and shortcoming that I wish to address here – EA
should provide the foundation for application development (AD) and
modernization.

The role of EA in AD lies in transforming abstract business
requirements from the problem space into concrete solutions that address these
requirements – while keeping all of the capabilities and solutions synchronized
to provide traceability.The most
successful organizations have adopted the SOA architectural style and apply it
at all levels of this transformation.At
the highest level, it involves depicting business requirements as capabilities
- discrete units of process, data and technology that allow you to accomplish
something of value.Modeling
capabilities (and their dependencies) is an important part of the Business
Architecture because it starts the componentization thought-process.As
you move across the problem/solution divide, these capabilities are transformed
into the services or solutions that implement them.

EA has two roles in this transformation.The first is to establish the rules and
parameters to guide the transformation. This includes setting standards,
similar to building codes, that must be adopted by development teams. These
include standards for development patterns, semantics and deployment platforms,
among others. While constraining, these
standards actually foster creativity and accelerate development because the
teams don't have to reinvent/readdress these issues – in the same way that
inventors of electrical appliances don’t have to worry about how to get
electricity to the appliance.The second
role for EA deals with the big picture. It
is to produce the overall (target) architecture of solutions, and the services
they consume, so that the development teams can build them out – similar to a
“table-top” model of a building or a community that shows how everything fits
together without providing the internal detail of each piece.The overall solution architecture as well as
the EA rules and constraints are provided to the acquisition process to be
incorporated into contract language that directs the design and development of
solutions. The solution architecture from the EA and the services consumed by
the solution are provided for incorporation in the RFPs and define what the
contractors are to build.

At the Solution Engineering phase of a program, EA should
provide the definitional clarity described above (denoting the components of
the architecture, their definitions, boundaries, and how they interoperate) as
well as more detailed artifacts to guide design and development, including
reference architectures and principles that identify patterns and platforms
that can/must be used by design/development teams.An example of a very successful architecture
principle at a high level is that all functionality must be service based, that
all interactions will occur through the service interfaces and that all service
interfaces must be externalizable.Amazon used this principle to implement all capabilities as services and
in the process created a business platform
to integrate all internal and external offerings. (ref.
Amazon; see Steve Yegge’s Rant, 2011).

During design and development, the EA team should perform
compliance reviews at appropriate stage gates to determine that the program is
building out the components of the architecture and is complying with the rules
and constraints.Today, most EA programs
review development progress “from an architectural perspective”.But without a model to compare it to, the
results are weak at best.In many cases,
development programs claim compliance with the EA because they can “map” their
application to the Reference Models, rather than demonstrating that they are
actually building out a part of a segment/domain architecture that will be reusable
by others.

The bottom line is that AD should operate in a manner
like most construction industries – develop an architecture and then build it,
preferably by assembling solutions from pre-built components.If the architecture is service based, it will
be modifiable on an incremental basis and thus should stand the test of
time.If the solution components are
specified and modeled in a rigorous manner, then automation (eg, code
generation) can accelerate the process and facilitate the
maintenance/enhancement process.

This is the concept that we at Everware-CBDI have based
our core competencies on.We call it Service
Oriented Application Modernization (SOAM) and it bridges EA and solution
development. SOAM consists of four
disciplines: SOA, Agile Development, Model Driven Development, and Portfolio
Transition Engineering.This approach
rapidly evolves the suite of IT assets to a set of rationalized, reusable
components that can be reconfigured to address new challenges.In the
process we are able to align development results with the business goals and
objectives.