Eeles on Architecture

Business Agility

2011-10-05T10:46:00.000-07:00

Time to breathe life back into my dormant blog! It's been a while - been buried helping many of my clients understand what it takes to become more agile.

One of the most enjoyable engagements has been helping Danske Bank transition to agile (see here) with a whole bunch of individuals for whom failure was never an option - both within the bank and within IBM. I'll be discussing success patterns in transforming a development organization at the UK Innovate event next week, if you're able to come along.

But this blog entry was actually prompted by a Twitter feed from @ibmrational who asked me "We'd love your input on what it means for a business to be #agile". The question is, itself, quite interesting since it's focused on business agility, and not IT agility, and rightly so.

And so my first observation is that business agility is much more than IT. To pick a non-IT example, business agility might be delivered through the ability to onboard partner organizations and suppliers more quickly, in order to respond to a market opportunity.

However, the second observation is that (for many organizations) IT is a critical aspect of their business, without which they would simply go out of business. The ability for IT to respond to business demands can make or break them. A very real example in the financial sector is the ability to change existing systems, quickly, in response to new regulations. In these cases, where business and IT go hand in hand, IT agility is inextricably linked to business agility.

The obvious next question is how IT becomes more agile. The growing consensus is that this is not just driven by process, but by architecture too. Watch this space :)

Architecting Development Environments

2010-07-14T01:09:00.000-07:00

No blogs for some time - I much prefer "micro blogs" and therefore use Twitter (http://twitter.com/petereeles) more often than Blogger. Anyhow, whenever something significant comes up I'll post here.

I've spent a considerable amount of time over the last few years focusing on a particular domain - development environments. I first described my thoughts in this paper. That work is undergoing a serious "refresh" and I'll be reporting back as collateral is created. The first item to be refined (based on lessons learned since that paper was written) is the definition of a development environment. The major elements have stayed the same (context, method, tools, enablement, organization, infrastructure and adoption), but my team and I have been teasing apart the different considerations when either defining, deploying or managing a development environment.

It's really interesting work and will underpin (for example) an architecture description standard for development environments (with relevant viewpoints defined) and a maturity model for development environments that extends CMMI. Watch this space!

Glad to see that the WICSA 2011 call for papers is now open.

What does Enterprise Architecture mean to you?

2010-01-30T04:31:00.000-08:00

I delivered some enablement yesterday for my colleagues and one item that resonated is Alan Brown's list of possible interpretations of what EA might mean to any given organisation:

1. An IT-driven initiative to define the IT application landscape

2. One source of the truth via an integrated view of the enterprise, across all lines of business

3. Assessing current and future states of the enterprise, along with the programs and controls to achieve desired capabilities

4. Architecture framework governance and reporting (e.g. Zachman, TOGAF, EA3, FEAF, MoDAF, DoDAF)

5. Portfolio planning for resources, projects and initiatives

6. “Uber-architecture” for development teams

7. Architectural conformance

8. Model-Driven Architecture (MDA)

9. Alignment of strategy, business, information, applications and technical infrastructure in support of a strategic intent

I prefer the last definition :)

- Pete

RSC 2010

2009-11-16T13:42:00.000-08:00

The 2010 Rational Software Conference has now opened its call for papers. See http://www-01.ibm.com/software/rational/rsdc/.

Through the course of my career I've been the architect of software, systems, (parts of) enterprises and development environments. I'm seriously considering a paper entitled "How to Architect Anything" since the fundamental principles that underpin all (good) architecting are the same.

Enterprise Architecture (EA) and Technical Architecture (TA)

2009-11-14T14:35:00.000-08:00

Every now again I come across something simple, yet profound. The most-recent is on Grady Booch's blog at http://www.handbookofsoftwarearchitecture.com/:

"EA attends to the architecture of a business that uses technology. TA attends to the architecture of the software-intensive systems that support the business".

This simple statement embraces several messages (such as the linkage of business and IT), but one, in particular, is worth emphasizing: "EA attends to the architecture of a business". This is a great one-liner that really crystallises the emphasis of EA as opposed to TA, especially given that enterprise architects and software architects each deal with applications, technology and data. And, yet, their focus is quite different - one is a system, the other is a business.

The 10 Keys to Successful Architecting

2009-08-20T00:16:00.000-07:00

I've been using the following "Top 10" keys to successful architecting lately - since it allows me to touch on almost every aspect of architecting - you might find it useful. Of course, there's a lot more behind each key - and if you're attending the Rational Software Conference in the UK (http://www-01.ibm.com/software/uk/itsolutions/developer/rational-software-conference-2009/) I'll be going into each of these in some detail. So ... here they are:

Successful software architects …

1. Understand end-to-end development
For example, they ... follow a repeatable process

2. Understand their role
For example, they ... understand what an architecture is
For example, they ... understand what an architect does
For example, they ... understand the benefits of architecting

3. Manage risk and manage change
For example, they ... derive their architectures iteratively

4. Communicate with stakeholders
For example, they ... document their architectures

5. Reuse assets
For example, they ... embrace different types of assets

6. Right-size their involvement
For example, they ... select relevant viewpoints

7. Influence the requirements
For example, they ... ensure tradeoffs are negotiated

8. Derive solutions from business needs
For example, they ... produce business-driven architectures

9. Refine solutions based on technology
For example, they ... realize architectures in available technology

10. Appreciate the broader context
For example, they ... align their work with the “bigger picture”

Context is Everything

2009-07-29T15:50:00.000-07:00

I met a very nice chap today, who was introduced as "the Architect". Even his business card had "VP of Architecture" on it. I nearly fell into the trap of assuming he was an IT architect interested in all things software (and more besides). Turns out he was an enterprise architect and that IT was just one part of his remit. I'm glad I asked (and yes, we did have a good conversation once that contextual information was shared!).

I know it's obvious, but it's essential (and reasonable) to ask an "architect" what they actually do when they tell you they're an architect. I mean, there are enough different architecture-related roles out there - enterprise architect, system architect, software architect, infrastructure architect, security architect etc. etc. and if someone told you they were a "manager" you wouldn't think twice about asking them what they manage! And some "architects" really aren't - but that's a longer blog :)

And as for the title of this blog - "Eeles on Architecture" seemed to roll off the tongue better than some of the alternatives!