Comments on: The Value of Enterprise Architecture http://www.soabloke.com/2009/06/16/the-value-of-enterprise-architecture/ pushing soa up the slope (with a pointy stick) Wed, 04 Aug 2010 15:33:11 -0700 hourly 1 http://wordpress.org/?v=3.0.1 By: EA and Agile Projects | soabloke http://www.soabloke.com/2009/06/16/the-value-of-enterprise-architecture/comment-page-1/#comment-614 EA and Agile Projects | soabloke Thu, 13 Aug 2009 22:20:13 +0000 http://www.soabloke.com/?p=88#comment-614 [...] recent comment on my post about the value of enterprise architecture suggested that enterprise architects should [...] [...] recent comment on my post about the value of enterprise architecture suggested that enterprise architects should [...]

]]> By: Saul http://www.soabloke.com/2009/06/16/the-value-of-enterprise-architecture/comment-page-1/#comment-611 Saul Tue, 04 Aug 2009 10:34:09 +0000 http://www.soabloke.com/?p=88#comment-611 Hi Paul, thanks for your thoughts on this and I agree that there is a lot of value that can come from EA being more involved and in-touch with the development teams. The EA team is a stakeholder or customer of a project just as much as the "business" is. Hence in an Agile approach if it makes sense for the business to be embedded in the project, then the same applies to the EA team. I <a href="http://www.soabloke.com/2008/02/13/the-soa-governance-thing/" rel="nofollow">share your concern</a> that governance is often viewed as a constraint rather than an enabler. Ultimately governance is a vehicle to enable continuity. How governance happens is <a href="http://www.soabloke.com/2008/06/10/venus-and-mars/" rel="nofollow">cultural</a>, and like many such thing, the culture can be good and supportive or bad and restrictive. Regards, Saul Hi Paul, thanks for your thoughts on this and I agree that there is a lot of value that can come from EA being more involved and in-touch with the development teams.

The EA team is a stakeholder or customer of a project just as much as the “business” is. Hence in an Agile approach if it makes sense for the business to be embedded in the project, then the same applies to the EA team.

I share your concern that governance is often viewed as a constraint rather than an enabler.

Ultimately governance is a vehicle to enable continuity. How governance happens is cultural, and like many such thing, the culture can be good and supportive or bad and restrictive.

Regards,
Saul

]]> By: Paul Boos http://www.soabloke.com/2009/06/16/the-value-of-enterprise-architecture/comment-page-1/#comment-610 Paul Boos Mon, 03 Aug 2009 13:21:49 +0000 http://www.soabloke.com/?p=88#comment-610 Based on the article, perhaps every Agile team should have an EA 'pig' (if we want to focus on a Scrum approach) attached to a development project. It would be their goal to assist developers in understanding what components they could integrate, helping the Product Owner understand the business benefit, help the team to ID and lower risks, and also to feed back into the EA those components that will change or be added as they evolve because of business-driven needs. It will help the organization realize the impacts ahead of deployment without being dictatorial about it. Finding some continual evolutionary process seems a way to integrate the Agile (short) and EA's (longer) cycles. I have been giving quite a bit of thought to how EA can assist an organization be more Agile without getting in the way of development and without having to attach itself to a specific technological approach (i.e. web services) since EA is about understanding business processes and data as well. I don't have any answers yet as I have just started researching this myself, but I am a strong proponent that the various architectural perspectives/views and associated 'governance' (if self-managed teams even need such a thing) should be there to help, not hinder. EA is more about providing information to help in, not as a constraint to, decision-making. Paul Based on the article, perhaps every Agile team should have an EA ‘pig’ (if we want to focus on a Scrum approach) attached to a development project. It would be their goal to assist developers in understanding what components they could integrate, helping the Product Owner understand the business benefit, help the team to ID and lower risks, and also to feed back into the EA those components that will change or be added as they evolve because of business-driven needs. It will help the organization realize the impacts ahead of deployment without being dictatorial about it.

Finding some continual evolutionary process seems a way to integrate the Agile (short) and EA’s (longer) cycles. I have been giving quite a bit of thought to how EA can assist an organization be more Agile without getting in the way of development and without having to attach itself to a specific technological approach (i.e. web services) since EA is about understanding business processes and data as well. I don’t have any answers yet as I have just started researching this myself, but I am a strong proponent that the various architectural perspectives/views and associated ‘governance’ (if self-managed teams even need such a thing) should be there to help, not hinder. EA is more about providing information to help in, not as a constraint to, decision-making.

Paul

]]> By: Enterprise Architecture is not the same for everyone - The Next Big Thing - http://www.soabloke.com/2009/06/16/the-value-of-enterprise-architecture/comment-page-1/#comment-605 Enterprise Architecture is not the same for everyone - The Next Big Thing - Thu, 09 Jul 2009 19:42:01 +0000 http://www.soabloke.com/?p=88#comment-605 [...] create a value proposition that holds up. One important question that must be answered is: Is the Enterprise Architecture closer to the CEO or the CIO based on the kind of CIO a company [...] [...] create a value proposition that holds up. One important question that must be answered is: Is the Enterprise Architecture closer to the CEO or the CIO based on the kind of CIO a company [...]

]]> By: Peter Evans-Greenwood http://www.soabloke.com/2009/06/16/the-value-of-enterprise-architecture/comment-page-1/#comment-597 Peter Evans-Greenwood Wed, 17 Jun 2009 01:55:33 +0000 http://www.soabloke.com/?p=88#comment-597 Richard makes an excellent point. We need to consider why EA's value proposition is poorly understood by most practitioners before we tackle bigger questions. There's too much blind following of method, and not enough thought into EA's role in the business. Witness the common tendency too staff EA teams by hiring someone into each role defined by TOGAF. Any value proposition must also be defined in terms the customer cares about. Defining ourselves in term of "transformation", "projects", "IT assets" or "governance" is a path to irrelevance. Enterprise technology and its role in business has changed dramatically since EA started--with applications becoming commoditized and the emergence of alternatives like SaaS--and we need to change with it. EA is becoming an advisory function. EAs should work with and across the business to help the business leverage technology to drive performance. Something this might mean procuring a technology asset, but increasingly it means engaging an external partner (BPO) or service (SaaS). Our value prop needs to be defined in how we help drive business value, not how we spend CAPEX. More thoughts in a preso I gave to RMIT's masters in EA class. http://peter.evans-greenwood.com/2009/05/07/the-value-of-enterprise-architecture/ r. PEG Richard makes an excellent point. We need to consider why EA’s value proposition is poorly understood by most practitioners before we tackle bigger questions. There’s too much blind following of method, and not enough thought into EA’s role in the business. Witness the common tendency too staff EA teams by hiring someone into each role defined by TOGAF.

Any value proposition must also be defined in terms the customer cares about. Defining ourselves in term of “transformation”, “projects”, “IT assets” or “governance” is a path to irrelevance. Enterprise technology and its role in business has changed dramatically since EA started–with applications becoming commoditized and the emergence of alternatives like SaaS–and we need to change with it.

EA is becoming an advisory function. EAs should work with and across the business to help the business leverage technology to drive performance. Something this might mean procuring a technology asset, but increasingly it means engaging an external partner (BPO) or service (SaaS). Our value prop needs to be defined in how we help drive business value, not how we spend CAPEX.

More thoughts in a preso I gave to RMIT’s masters in EA class.
http://peter.evans-greenwood.com/2009/05/07/the-value-of-enterprise-architecture/

r.

PEG

]]> By: Richard Veryard http://www.soabloke.com/2009/06/16/the-value-of-enterprise-architecture/comment-page-1/#comment-596 Richard Veryard Tue, 16 Jun 2009 13:29:13 +0000 http://www.soabloke.com/?p=88#comment-596 Of course. How can the value proposition for enterprise architecture ever be understood (let alone trusted) by its customers when it doesn't seem to be very clearly or consistently understood even by its practitioners? I think a value proposition along the lines you suggest could be very powerful. Chris Bird suggested something similar to yours in a comment to my blog. My suggestion is that we should try to use Osterwalder's template to lay out a value proposition for EA in a systematic fashion. I am working on one, and I invite you to have a go as well. Of course. How can the value proposition for enterprise architecture ever be understood (let alone trusted) by its customers when it doesn’t seem to be very clearly or consistently understood even by its practitioners?

I think a value proposition along the lines you suggest could be very powerful. Chris Bird suggested something similar to yours in a comment to my blog.

My suggestion is that we should try to use Osterwalder’s template to lay out a value proposition for EA in a systematic fashion. I am working on one, and I invite you to have a go as well.

]]>