Blog moved here:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/petereeles/?lang=en
And I've started blogging again :)
Sunday 23 September 2012
Wednesday 5 October 2011
Business Agility
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 :)
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
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 :)
Wednesday 14 July 2010
Architecting Development Environments
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.
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.
Saturday 30 January 2010
What does Enterprise Architecture mean to you?
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
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
Monday 16 November 2009
RSC 2010
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.
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.
Saturday 14 November 2009
Enterprise Architecture (EA) and Technical Architecture (TA)
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.
"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.
Thursday 20 August 2009
The 10 Keys to Successful Architecting
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”
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”
Subscribe to:
Posts (Atom)
