Agile Architecture ©

In an upcoming paper on road mapping an Enterprise Architecture I am outlining the principles behind an Agile Enterprise Architecture delivery method.  Before the paper is completed I want to discuss the fundamentals of the agile approach and the reasons I am  motivated to develop it.

The fundamentals of this delivery method encompass a fusion of best practices from agile software development, and a hybrid of the architecture delivery methods as outlined in DoDAF 2.0 and TOGAF 9.0 architecture frameworks. I am not redefining or changing agile techniques, nor altering architecture delivery methods in the established frameworks.  This is a marriage of  industry proven processes and principles that brings the benefits of agile software development methodologies to enterprise architecture development.

The motivations behind tying agile methodologies to architectural delivery method (ADM) are listed below in no particular order.

1. Bring continuous process improvement to all phases of the ADM.
2. Introduce metrics and KPI's from lean systems engineering and agile methodologies into ADM.
3. Insure the most suitable architecture addressing the problem domains is being developed.
4. Speed time to deployment of actual architecture.

Philosophically I am striving to create the most usable end products from a complex problem set.  We have a rich and complete set of models in DoDAF, delivery method in TOGAF, and an empirical process control model exercised through agile methodology.

How best to tie these together is the quest, and I am traveling iteratively and aggressively towards this goal.

Jazz and Computer Science?

I love this recent quote from American master musician Wynton Marsalis regarding his skills and the complexity of the music he plays. His attitude  resonates with me as a computer scientist and lover of challenges.

I like pressure, I like that, I like the challenge, I don't have a problem with it at all. I like the feeling of nervousness, I like the feeling that something counts, and I like to be tested 

-Wynton Marsalis 

I thought this was inspiring, you can see the entire interview linked below. Includes links to a Part II filmed in Havana Cuba.

Wynton Marsalis Interview

Business Rules and SOA Policy

Blogger Randy Heffner posted an interesting piece on business rules and SOA policy. The takeaway for me is a focus on both domain specific languages that allow business users (non programmers)access to logic that used to reside in source code, and the tools, governance, and policies surrounding making changes in that logic.

If  I'm the Captain of a ship at sea and I desire a change in the way a system behaves or process executes, how can I change it NOW.

Business 2011 Gets Faster; Business Rules And SOA Policy Get More Important
Posted by Randy Heffner on December 7, 2010

Can you remember a year when your business both (1) grew in a healthy way and (2) changed more slowly than the year before? Besides a company’s early startup years, such would be the exception, not the rule. So, in 2011, your business is likely to continue accelerating its pace of change. A recent Forrester report, The Top 15 Technology Trends EA Should Watch: 2011 To 2013, named both business rules and SOA policy as items for your watch list — because both of them help accelerate business change.

Back in the mainframe days — and even into minicomputer, client/server, and Web applications — nearly all of the business logic for every application was tightly wrapped up in the application code. A few forward-thinking programmers might have built separate parameter files with a small bit of business-oriented application configuration, but that was about it. But, business changes too quickly to have all of the rules locked up in the code.

Some have tried the route that businesspeople ought to do their own programming — and many vendor tools through the years have tried creatively (though unsuccessfully) to make development simple enough for that. But, business is too complex for businesspeople to do all of their own programming.

Enter business rules, SOA policy, and other ways to pull certain bits of business logic out of being buried in the code. What makes these types of approaches valuable is that they are targeted, contained, and can have appropriate life cycles built around them to allow businesspeople to change what they are qualified to change, authorized to change, and have been approved to change.

Although neither makes the headlines like cloud and such, 2011 will see continued adoption and growth of business rules and SOA policy. Business rules technology is much farther along in adoption than SOA policy — as it should be. SOA policy requires much more architectural work, particularly when (a) used beyond its core of security policy and management policy or (b) set up to allow businesspeople to do their own change.

But here's the crux of the matter: Both business rules and SOA policy are part of a much broader trend to build software around flexible business design focal points. Do you need to start or expand your adoption of them in 2011? Perhaps, but only if you do your homework so that you'll get the value. The important things to focus on are (1) understanding where and how your business most needs flexibility and (2) using business rules, SOA policy, business process flow, and other techniques and technologies to accelerate your ability to change the business.

- Randy Heffner

Enterprise Decision Management Screencast IIIa

Enterprise Decision Management Screencasts in HD on YouTube

Screen casts are also available in HD on YouTube directly. Hope you enjoy, Part III is being worked on.

www.aeitg.com

Enterprise Decision Management Screencast Part II