This might be my last post, or atleast for a while... I have decided to leave SSE, and have about two months or so, to make a decision as to where I go next. If you, or anyone else you know, might find someone like me useful for an organisation, please let me know.
I am considering an MBA, potentially an equivalent and/or part-time. For me, an organisation's support towards this for their EAs would be a key aspect of my choice. We have kicked off many discussions in and out of this network about the business benefits to an EA and their organisation. I'm sure many of you would have a lot of positive and negative responses towards speaking the same language as the business owners. Should we lean towards the business owners and assist them in making decisions? Or should EAs lean towards operations/IT and assist them in designing and implementing the decisions which have been made? We probably can't go towards either extreme... I would like to understand your opinion.
Over the past few years, I have been in close contact with many of you, and just wanted to let you all know. Please don't flame me. I will not be available on this email address any more... :-)
Best regards,
Joseph
_______________
Joseph George
+44 7951 499286 (please note change)
http://uk.linkedin.com/in/josephg
Center for Government Interoperability
tags
gov,
integration,
tea.net
Alex,
Good initiative! I like the idea... But, if you wish "to promote data interoperability in government", I would suggest looking at data.gov and app.gov, and either drive those standards or follow them. At the moment, unless some other initiative overtakes them, I would say that data.gov and apps.gov are driving innovation across the US.
In the UK, we have the data.gov.uk, setting the standards for data-interchange and cross-departmental initiatives to standardise on government architecture in data and app.
Best regards,
Joseph
_______________
Joseph George
+44 7951 499286 (please note change)
http://uk.linkedin.com/in/josephg
On Aug 26, 4:49 pm, rmurthy wrote:
> Alex,
> Few years earlier, there were some initiatives from US DOJ to
> standardize interfaces for data sharing among various agencies. One of
> them was called the DOJXML initiative. You may want to look it up.
> Best,
> Rajesh
> On Aug 9, 11:20 am, AlexGlaros wrote:
> > I'm seeking feedback on an organization I’m considering starting to
> > promote data interoperability in government: Center for Government
> > Interoperability
> >http://gov-ideas.com/cfgio.htm
> > My contact info is on the site if you prefer to contact me privately.
> > Any feedback is much appreciated,
> > Alex Glaros
Good initiative! I like the idea... But, if you wish "to promote data interoperability in government", I would suggest looking at data.gov and app.gov, and either drive those standards or follow them. At the moment, unless some other initiative overtakes them, I would say that data.gov and apps.gov are driving innovation across the US.
In the UK, we have the data.gov.uk, setting the standards for data-interchange and cross-departmental initiatives to standardise on government architecture in data and app.
Best regards,
Joseph
_______________
Joseph George
+44 7951 499286 (please note change)
http://uk.linkedin.com/in/josephg
On Aug 26, 4:49 pm, rmurthy
> Alex,
> Few years earlier, there were some initiatives from US DOJ to
> standardize interfaces for data sharing among various agencies. One of
> them was called the DOJXML initiative. You may want to look it up.
> Best,
> Rajesh
> On Aug 9, 11:20 am, AlexGlaros
> > I'm seeking feedback on an organization I’m considering starting to
> > promote data interoperability in government: Center for Government
> > Interoperability
> >http://gov-ideas.com/cfgio.htm
> > My contact info is on the site if you prefer to contact me privately.
> > Any feedback is much appreciated,
> > Alex Glaros
Cultural Alignment of Business Systems
tags
culture,
integration,
leadership,
principles,
tea.net
Tim,
If you can slot your organisational culture into a rigid system, then by all means you can align or, at the very least, emulate your business sytems to reflect your culture. IMHO, from what I have seen in many organisations, culture has two aspects:
1. that which the leadership or the organisation wishes to inculcate down the heirarchy - the documented visible mission, vision, values, etc. which are formally available.
2. that which the leadership or the organisation is trying to get rid of - the invisible, undocumented, unstructured, unacknowledged behaviour exhibited by the heirarchy and emulated down the chain.
It is very easy to work with (1), and your could formulate and align architectural principles on a one-to-one basis. But, what is more important is tackling (2), and I think that is more value-add and more difficult. Particularly if you are an external entity, you might find (2) might be difficult to get a handle on.
I would suggest working with some experts on Organisational Behaviour, in order to achieve your goal. But, again IMHO, that is entirely the CEO's responsibility. You could take an architectural approach, but everything is not black and white, in this sense. :-)
In one of my discussions with our CEO, I referred him to an article (not mine, all credits to the original author), which I am happy to mention here, if it would be of any help re this context:
< snip >
Leadership as ‘Intentional Influence’, by George Ambler
The article “Leadership: Intentional Influence” from BusinessWeek provide an interesting discussion on the topic of leadership. Research by the company VitalSmarts uncovered the following key insights that help to understand why few leaders are able to exert influence.
1. Leaders act as if it’s not their job to address entrenched habits.
“Most leaders put a great deal of time into crafting strategy, selecting winning products, and engaging with analysts, shareholders, and major customers. But few realize the success or failure of their grand schemes lies in influencing the behavior of the hundreds or thousands of people who will have to execute the big ideas — their employees.
2. Leaders lack a theory of influence.
“Very few leaders can even answer the question, "How do you change the behavior of a large group of people?" And yet, this is what they’re ultimately paid to do. It isn’t just about making a decision; it’s about getting people aligned to execute the decision. And this means influence….”
3. Leaders confuse talking with influencing.
“Many leaders think influence consists of little more than talking people into doing things… Anyone who’s ever tried to talk a smoker into quitting knows there’s a lot more to behavior change than words…”
4. Leaders believe in silver bullets.
“When leaders actually attempt to influence new behavior, it’s common for them to look for quick fixes—to fall into the trap of thinking that deeply ingrained bad habits can be changed with a single technique. The failure mode is to rely on any single approach…”
< /snip >
Best regards,
Joseph
_______________
Joseph George
+44 (0)7951 499286 (please note change)
http://uk.linkedin.com/in/josephg
On Aug 6, 1:57 am, Tim Leigh wrote:
> Thanks for all the useful feedback re: cultural alignment of business
> systems, this forum is one of the best EA resources I’ve found.
> To answer a question, some high level examples of cultural values which we
> are trying to align with are:
> · Client centric
> · Empowered people and teams
> I’d like to take these high level culture/objective statements and expand on
> them within a framework, as the aim of the review is to assess how our
> systems reinforce or compete with the envisioned culture.
> Thanks for the suggestion of VSM, as this appears to be a good approach
> which I wasn’t aware of and seems to be a good way for us to go.
If you can slot your organisational culture into a rigid system, then by all means you can align or, at the very least, emulate your business sytems to reflect your culture. IMHO, from what I have seen in many organisations, culture has two aspects:
1. that which the leadership or the organisation wishes to inculcate down the heirarchy - the documented visible mission, vision, values, etc. which are formally available.
2. that which the leadership or the organisation is trying to get rid of - the invisible, undocumented, unstructured, unacknowledged behaviour exhibited by the heirarchy and emulated down the chain.
It is very easy to work with (1), and your could formulate and align architectural principles on a one-to-one basis. But, what is more important is tackling (2), and I think that is more value-add and more difficult. Particularly if you are an external entity, you might find (2) might be difficult to get a handle on.
I would suggest working with some experts on Organisational Behaviour, in order to achieve your goal. But, again IMHO, that is entirely the CEO's responsibility. You could take an architectural approach, but everything is not black and white, in this sense. :-)
In one of my discussions with our CEO, I referred him to an article (not mine, all credits to the original author), which I am happy to mention here, if it would be of any help re this context:
< snip >
Leadership as ‘Intentional Influence’, by George Ambler
The article “Leadership: Intentional Influence” from BusinessWeek provide an interesting discussion on the topic of leadership. Research by the company VitalSmarts uncovered the following key insights that help to understand why few leaders are able to exert influence.
1. Leaders act as if it’s not their job to address entrenched habits.
“Most leaders put a great deal of time into crafting strategy, selecting winning products, and engaging with analysts, shareholders, and major customers. But few realize the success or failure of their grand schemes lies in influencing the behavior of the hundreds or thousands of people who will have to execute the big ideas — their employees.
2. Leaders lack a theory of influence.
“Very few leaders can even answer the question, "How do you change the behavior of a large group of people?" And yet, this is what they’re ultimately paid to do. It isn’t just about making a decision; it’s about getting people aligned to execute the decision. And this means influence….”
3. Leaders confuse talking with influencing.
“Many leaders think influence consists of little more than talking people into doing things… Anyone who’s ever tried to talk a smoker into quitting knows there’s a lot more to behavior change than words…”
4. Leaders believe in silver bullets.
“When leaders actually attempt to influence new behavior, it’s common for them to look for quick fixes—to fall into the trap of thinking that deeply ingrained bad habits can be changed with a single technique. The failure mode is to rely on any single approach…”
< /snip >
Best regards,
Joseph
_______________
Joseph George
+44 (0)7951 499286 (please note change)
http://uk.linkedin.com/in/josephg
On Aug 6, 1:57 am, Tim Leigh
> Thanks for all the useful feedback re: cultural alignment of business
> systems, this forum is one of the best EA resources I’ve found.
> To answer a question, some high level examples of cultural values which we
> are trying to align with are:
> · Client centric
> · Empowered people and teams
> I’d like to take these high level culture/objective statements and expand on
> them within a framework, as the aim of the review is to assess how our
> systems reinforce or compete with the envisioned culture.
> Thanks for the suggestion of VSM, as this appears to be a good approach
> which I wasn’t aware of and seems to be a good way for us to go.
Technology Consolidation
tags
cloud,
consolidation,
tea.net
Hello Ramesh,
On a recent engagement, I focussed on business consolidation and rationalisation. I noticed that the technology stacks simply followed across, and the decision making became much easier. To put it plainly, it is very difficult to choose between potatoes and onions. But, once you know what the end goal is, your decision becomes much easier.
However, many organisations are driven bottom-up rather than the top-down approach used above. In that case, your technology consolidation might end up driving business consolidation. Good luck, in that case! If you don't end up with any business consolidation, I see no business benefits from technology consolidation. IT, in this case, is a white elephant needing to be sorted on its own, or thrown out!
Technology roadmaps from vendors or suppliers are very helpful to understand the cost/benefits of remaining with any particular technology. Throw out any technology which continues to increase in annual costs, without any corresponding increase in business benefits.
Evaluate from a business perspective, whether it might be worthwhile outsourcing, if your business finds it very difficult to make IT decisions. But, the key to successful outsourcing is in having a business partnership, rather than a pure technology supplier relationship. A totally different topic... :-)
Explore the potential of the cloud... another topic on its own! But, something to be considered, if you are evaluating your options. Get a cost-analysis done, and present to your business owners, rather than to IT. This option is best suitable for startups, or organisations going through a radical overhaul. Sounds like yours might be one!
Best regards,
Joseph
_______________
Joseph George
+44 (0)78250 15480
http://uk.linkedin.com/in/josephg
On Jul 12, 11:29 pm, ramesh appat wrote:
> Hello,
> Do any of you have a process or methodology that you have used/executed in
> your company or with a client to help them arrive at technology
> consolidation? Any material pertaining to this will be helpful.
On a recent engagement, I focussed on business consolidation and rationalisation. I noticed that the technology stacks simply followed across, and the decision making became much easier. To put it plainly, it is very difficult to choose between potatoes and onions. But, once you know what the end goal is, your decision becomes much easier.
However, many organisations are driven bottom-up rather than the top-down approach used above. In that case, your technology consolidation might end up driving business consolidation. Good luck, in that case! If you don't end up with any business consolidation, I see no business benefits from technology consolidation. IT, in this case, is a white elephant needing to be sorted on its own, or thrown out!
Technology roadmaps from vendors or suppliers are very helpful to understand the cost/benefits of remaining with any particular technology. Throw out any technology which continues to increase in annual costs, without any corresponding increase in business benefits.
Evaluate from a business perspective, whether it might be worthwhile outsourcing, if your business finds it very difficult to make IT decisions. But, the key to successful outsourcing is in having a business partnership, rather than a pure technology supplier relationship. A totally different topic... :-)
Explore the potential of the cloud... another topic on its own! But, something to be considered, if you are evaluating your options. Get a cost-analysis done, and present to your business owners, rather than to IT. This option is best suitable for startups, or organisations going through a radical overhaul. Sounds like yours might be one!
Best regards,
Joseph
_______________
Joseph George
+44 (0)78250 15480
http://uk.linkedin.com/in/josephg
On Jul 12, 11:29 pm, ramesh appat
> Hello,
> Do any of you have a process or methodology that you have used/executed in
> your company or with a client to help them arrive at technology
> consolidation? Any material pertaining to this will be helpful.
Distributing the role of Enterprise Architect across the firm
tags
collaborative,
culture,
leadership,
strategy,
tea.net
> Distributing the role so that it is shared among the firms
> knowledge workers is necessary. Not just the doing, but
> the thinking, and negotiating as independent agents.
Good point, Martin! Traditionally, the role of EA had been very distributed across the organisation and within the remit of many different roles stretching horizontally and vertically. The EA panacea that we seem to be heading towards is bringing all that within a single role or team of EAs. I don't think that is practical and/or feasible. It is good to have all decision making within a single coherent group. But the realities of a global enterprise are best understood by people owning specific functions closer to ground level.
Key words that I picked up from your posts are - "inspire and fund", "distributing the role", "shared knowledge", "independant agents", "transparency", "tools", "healthy culture", "equip each worker". Very good! Ensuring all these are outside the remit of the EA, but very much driven by the organisational leadership. Any lack of these directly impacts the results of EA, potentially leading to EA failure.
> leadership can inspire and fund rather than command and control.
Yes, that was the old model of leadership - command and control. The new model seems to be very much inspire and support (or fund, as you say). But, we need knowledgable and intelligent leaders who understand the ramifications of their decisions. That is what I currently see some corporate leaders lacking. The ownership and liability of business failure is very much the business owners'. They can not and should not try to pawn off any failure to others lower down the chain, as we see in some global companies. I see this potentially becoming an EA liability.
> EA done properly removes/eradicates many of the
> "problems" associated with a lot of other people view of EA.
> We need a big team of highly paid Enterprise Architects
> - No you don't
> We need a dedicated group of people to keep the "models"
> up to date - No you don't
> We need a big EA project to move us from the as-is to
> the to-be - No you don't
> We need to create a whole new set of processes,
> job titles and departments - No you don't
> We need Enterprise Architects to make strategic decisions
> - No you don't
Kevin, very well put! Organisations are reticient to embrace what they don't understand. EA seems to be something very difficult to grasp, and we don't help in removing this fallacy by making the EA more and more complicated. I think EA (or rather the BA portion of EA) is simply some of the old-fashioned business management consulting techniques integrated vertically with the newer models of "doing" business and supporting virtual operations.
Best regards,
Joseph
_______________
Joseph George
+44 (0)78250 15480
http://uk.linkedin.com/in/josephg
On Jul 20, 5:14 pm, Martin Cleaver wrote:
> > If an organisation were working as a well-oiled machine, it would
> > not need an EA. Hence, an EA would be working themselves out of a
> > job. But, the market evolves, the organisation
> > evolves, the people/roles evolve. And so, the EA has a constant stream
> > of inputs necessitating realigning the to-be system (organisation) and
> > working out the impacts.
> Reminds me: Command & Control can only get us so far. CxO positions -
> and by extension, EA positions - typically take a top-down mandate.
> But top-down roles can't see everything, can't interpret and
> prioritize everything and can't orchestrate everyone.
> Distributing the role so that it is shared among the firms knowledge
> workers is necessary. Not just the doing, but the thinking, and
> negotiating as independent agents.
> Transparency and tools are necessary. Transparency to see observe
> what's going on, with a healthy culture that invigourates change and
> leadership from within. Tools to enable transparency and to equip each
> worker with the means to apply rational method to domains the worker
> is unfamiliar with.
> Together these equip workers with the inputs, the understanding, and
> the engagement to make impact.
> Then leadership can inspire and fund rather than command and control.
> In short, I'd be fascinated to see the tool EAs use made available to
> all knowledge workers in an enterprise.
> Best, Martin
> Martin Cleaver MSc MBA
> Sent from my iPhone, so it might be quicker to call me, on +1-416-786-6752
> On 2010-07-19, at 8:49 AM, Joseph George > wrote:
> > Bill,
> >> An EA is a mini CxO type that is
> >> exists to work themselves out of a job
> > I agree with you on the above. I have been saying that all along.
> > Search this group for the discussion thread ("Architects" of the
> > Enterprise?) among others.
> > The only people I see playing an EA role are the CxOs (to continue the
> > American euphemism) within their remit. Anyone else is just applying
> > the finishing touches or working out the finer details. And that
> > means, an EA becomes a CxO representative involved in aspects lacking
> > in the respective CxO. If an organisation were working as a well-oiled
> > machine, it would not need an EA. Hence, an EA would be working
> > themselves out of a job. But, the market evolves, the organisation
> > evolves, the people/roles evolve. And so, the EA has a constant stream
> > of inputs necessitating realigning the to-be system (organisation) and
> > working out the impacts.
> > I don't think EA is about Frameworks, but they do help in terms of
> > providing a structure and/or methodology.
> >>>>>> I'd like to get a feel for how many EA's there are in the world.
> > Much of what is being touted about in this group as to-be EA is imho
> > BA. Atleast that is what I see where Kirk is aiming - pure Business
> > Architecture. I don't think you can disconnect a business (and its
> > Business Architecture) from its operations (or Information
> > Architecture and Technology Architecture).
> >>>>>> I'd like to get a feel for how many EA's there are in the world.
> > Back to the OP, I think Gerald would struggle to get any sort of valid
> > statistics to justify any claim. I would even wonder about the
> > purpose. The world is a large place with a lot of organisations. I see
> > many who I think are operating as EAs, who do not have any such title
> > nor would want to be known as EAs. On the other hand, I meet people
> > with EA in their title, whose sponsors themselves do not understand
> > what EA is about.
> > Best regards,
> > Joseph George
> > +44 (0)78250 15480
> >http://uk.linkedin.com/in/josephg
> > On Jul 14, 7:42 pm, Bill wrote:
> >> Kirk,
> >> Excellent point and very valid as well. We must understand, however,
> >> that this subject is more than a personal training issues. This is a
> >> global and corporate training issue. Do a Dice, Monster, Indeed, etc.
> >> search for EA and you will get nigh 100% IT Architects that deal with
> >> something 'enterprise' (e.g. has an enterprise commitment,
> >> distribution, or effect). This is the information or mis-information
> >> that has been projected ever since the term 'architect' gained
> >> popularity.
> >> Let me explain my thoughts on an EA: An EA is a mini CxO type that is
> >> exists to work themselves out of a job by recreating, restructuring,
> >> and redefining the business. Many people think of this person as a
> >> 'super' project manager, but, there's much more to it. This person is
> >> part business-person, manager, executive, technologist, HR
> >> representative, project manager, and evangelist. At any given time
> >> there will be aspects of these positions being performed by the EA.
> >> Thus, this is where many see IT involvement of the EA. Organizations
> >> are still defining their technology and its integration with business
> >> and this is why technology finds its way, more often than not, into
> >> the EA portfolio. The EA works themselves out of a job by
> >> integrating
> >> the next phase of the vision and mission into the processes, people,
> >> and structures of the organization. They then move to the next phase
> >> and start over.
> >> The future of technology is full integration into the business of the
> >> organization. This is a transparency of technology that looks a
> >> lot> > > >> I'd like to get a feel for how many EA's there are in
> >> the world.
> >> like commoditization. I personally do not believe that it is a
> >> "Nicholas Carr" type of commoditization where technology is like a
> >> light switch and technologists need 'business smarts'. No, I think it
> >> is the other way around. The business will incorporate and utilize
> >> 'technology smarts' and what we know of IT now will be more fully
> >> automated, measurable, and structured for use/re-use (business people
> >> will need technology smarts as well as technologists needing business
> >> smarts).
> >> It is like any trend. Look at mass production. Automobile
> >> manufacturers (even fast food companies) went through similar efforts
> >> to restructure their services to accommodate mass production. Indoor
> >> plumbing, passenger airplanes, and a number of other trends in
> >> efficiency and productivity can be used to understand the EA
> >> movement.
> >> In any event, we are in the midst of a high flux period while
> >> technology grants increased capability to the EA. As such (and during
> >> such) we have a continual training process to perform in the
> >> organizations of the world. Thus, I agree with your previous
> >> statement; in the realization of each phase, everyone in an
> >> organization can be said to be doing enterprise architecture. And
> knowledge workers is necessary. Not just the doing, but
> the thinking, and negotiating as independent agents.
Good point, Martin! Traditionally, the role of EA had been very distributed across the organisation and within the remit of many different roles stretching horizontally and vertically. The EA panacea that we seem to be heading towards is bringing all that within a single role or team of EAs. I don't think that is practical and/or feasible. It is good to have all decision making within a single coherent group. But the realities of a global enterprise are best understood by people owning specific functions closer to ground level.
Key words that I picked up from your posts are - "inspire and fund", "distributing the role", "shared knowledge", "independant agents", "transparency", "tools", "healthy culture", "equip each worker". Very good! Ensuring all these are outside the remit of the EA, but very much driven by the organisational leadership. Any lack of these directly impacts the results of EA, potentially leading to EA failure.
> leadership can inspire and fund rather than command and control.
Yes, that was the old model of leadership - command and control. The new model seems to be very much inspire and support (or fund, as you say). But, we need knowledgable and intelligent leaders who understand the ramifications of their decisions. That is what I currently see some corporate leaders lacking. The ownership and liability of business failure is very much the business owners'. They can not and should not try to pawn off any failure to others lower down the chain, as we see in some global companies. I see this potentially becoming an EA liability.
> EA done properly removes/eradicates many of the
> "problems" associated with a lot of other people view of EA.
> We need a big team of highly paid Enterprise Architects
> - No you don't
> We need a dedicated group of people to keep the "models"
> up to date - No you don't
> We need a big EA project to move us from the as-is to
> the to-be - No you don't
> We need to create a whole new set of processes,
> job titles and departments - No you don't
> We need Enterprise Architects to make strategic decisions
> - No you don't
Kevin, very well put! Organisations are reticient to embrace what they don't understand. EA seems to be something very difficult to grasp, and we don't help in removing this fallacy by making the EA more and more complicated. I think EA (or rather the BA portion of EA) is simply some of the old-fashioned business management consulting techniques integrated vertically with the newer models of "doing" business and supporting virtual operations.
Best regards,
Joseph
_______________
Joseph George
+44 (0)78250 15480
http://uk.linkedin.com/in/josephg
On Jul 20, 5:14 pm, Martin Cleaver
> > If an organisation were working as a well-oiled machine, it would
> > not need an EA. Hence, an EA would be working themselves out of a
> > job. But, the market evolves, the organisation
> > evolves, the people/roles evolve. And so, the EA has a constant stream
> > of inputs necessitating realigning the to-be system (organisation) and
> > working out the impacts.
> Reminds me: Command & Control can only get us so far. CxO positions -
> and by extension, EA positions - typically take a top-down mandate.
> But top-down roles can't see everything, can't interpret and
> prioritize everything and can't orchestrate everyone.
> Distributing the role so that it is shared among the firms knowledge
> workers is necessary. Not just the doing, but the thinking, and
> negotiating as independent agents.
> Transparency and tools are necessary. Transparency to see observe
> what's going on, with a healthy culture that invigourates change and
> leadership from within. Tools to enable transparency and to equip each
> worker with the means to apply rational method to domains the worker
> is unfamiliar with.
> Together these equip workers with the inputs, the understanding, and
> the engagement to make impact.
> Then leadership can inspire and fund rather than command and control.
> In short, I'd be fascinated to see the tool EAs use made available to
> all knowledge workers in an enterprise.
> Best, Martin
> Martin Cleaver MSc MBA
> Sent from my iPhone, so it might be quicker to call me, on +1-416-786-6752
> On 2010-07-19, at 8:49 AM, Joseph George
> > Bill,
> >> An EA is a mini CxO type that is
> >> exists to work themselves out of a job
> > I agree with you on the above. I have been saying that all along.
> > Search this group for the discussion thread ("Architects" of the
> > Enterprise?) among others.
> > The only people I see playing an EA role are the CxOs (to continue the
> > American euphemism) within their remit. Anyone else is just applying
> > the finishing touches or working out the finer details. And that
> > means, an EA becomes a CxO representative involved in aspects lacking
> > in the respective CxO. If an organisation were working as a well-oiled
> > machine, it would not need an EA. Hence, an EA would be working
> > themselves out of a job. But, the market evolves, the organisation
> > evolves, the people/roles evolve. And so, the EA has a constant stream
> > of inputs necessitating realigning the to-be system (organisation) and
> > working out the impacts.
> > I don't think EA is about Frameworks, but they do help in terms of
> > providing a structure and/or methodology.
> >>>>>> I'd like to get a feel for how many EA's there are in the world.
> > Much of what is being touted about in this group as to-be EA is imho
> > BA. Atleast that is what I see where Kirk is aiming - pure Business
> > Architecture. I don't think you can disconnect a business (and its
> > Business Architecture) from its operations (or Information
> > Architecture and Technology Architecture).
> >>>>>> I'd like to get a feel for how many EA's there are in the world.
> > Back to the OP, I think Gerald would struggle to get any sort of valid
> > statistics to justify any claim. I would even wonder about the
> > purpose. The world is a large place with a lot of organisations. I see
> > many who I think are operating as EAs, who do not have any such title
> > nor would want to be known as EAs. On the other hand, I meet people
> > with EA in their title, whose sponsors themselves do not understand
> > what EA is about.
> > Best regards,
> > Joseph George
> > +44 (0)78250 15480
> >http://uk.linkedin.com/in/josephg
> > On Jul 14, 7:42 pm, Bill
> >> Kirk,
> >> Excellent point and very valid as well. We must understand, however,
> >> that this subject is more than a personal training issues. This is a
> >> global and corporate training issue. Do a Dice, Monster, Indeed, etc.
> >> search for EA and you will get nigh 100% IT Architects that deal with
> >> something 'enterprise' (e.g. has an enterprise commitment,
> >> distribution, or effect). This is the information or mis-information
> >> that has been projected ever since the term 'architect' gained
> >> popularity.
> >> Let me explain my thoughts on an EA: An EA is a mini CxO type that is
> >> exists to work themselves out of a job by recreating, restructuring,
> >> and redefining the business. Many people think of this person as a
> >> 'super' project manager, but, there's much more to it. This person is
> >> part business-person, manager, executive, technologist, HR
> >> representative, project manager, and evangelist. At any given time
> >> there will be aspects of these positions being performed by the EA.
> >> Thus, this is where many see IT involvement of the EA. Organizations
> >> are still defining their technology and its integration with business
> >> and this is why technology finds its way, more often than not, into
> >> the EA portfolio. The EA works themselves out of a job by
> >> integrating
> >> the next phase of the vision and mission into the processes, people,
> >> and structures of the organization. They then move to the next phase
> >> and start over.
> >> The future of technology is full integration into the business of the
> >> organization. This is a transparency of technology that looks a
> >> lot> > > >> I'd like to get a feel for how many EA's there are in
> >> the world.
> >> like commoditization. I personally do not believe that it is a
> >> "Nicholas Carr" type of commoditization where technology is like a
> >> light switch and technologists need 'business smarts'. No, I think it
> >> is the other way around. The business will incorporate and utilize
> >> 'technology smarts' and what we know of IT now will be more fully
> >> automated, measurable, and structured for use/re-use (business people
> >> will need technology smarts as well as technologists needing business
> >> smarts).
> >> It is like any trend. Look at mass production. Automobile
> >> manufacturers (even fast food companies) went through similar efforts
> >> to restructure their services to accommodate mass production. Indoor
> >> plumbing, passenger airplanes, and a number of other trends in
> >> efficiency and productivity can be used to understand the EA
> >> movement.
> >> In any event, we are in the midst of a high flux period while
> >> technology grants increased capability to the EA. As such (and during
> >> such) we have a continual training process to perform in the
> >> organizations of the world. Thus, I agree with your previous
> >> statement; in the realization of each phase, everyone in an
> >> organization can be said to be doing enterprise architecture. And
How many Enterprise Architects are there in the world?
tags
business.architecture,
strategy,
tea.net
Bill,
> An EA is a mini CxO type that is
> exists to work themselves out of a job
I agree with you on the above. I have been saying that all along. Search this group for the discussion thread ("Architects" of the Enterprise?) among others.
The only people I see playing an EA role are the CxOs (to continue the American euphemism) within their remit. Anyone else is just applying the finishing touches or working out the finer details. And that means, an EA becomes a CxO representative involved in aspects lacking in the respective CxO. If an organisation were working as a well-oiled machine, it would not need an EA. Hence, an EA would be working themselves out of a job. But, the market evolves, the organisation evolves, the people/roles evolve. And so, the EA has a constant stream of inputs necessitating realigning the to-be system (organisation) and working out the impacts.
I don't think EA is about Frameworks, but they do help in terms of providing a structure and/or methodology.
Much of what is being touted about in this group as to-be EA is imho BA. Atleast that is what I see where Kirk is aiming - pure Business Architecture. I don't think you can disconnect a business (and its Business Architecture) from its operations (or Information Architecture and Technology Architecture).
> > > >> I'd like to get a feel for how many EA's there are in the world.
Back to the OP, I think Gerald would struggle to get any sort of valid statistics to justify any claim. I would even wonder about the purpose. The world is a large place with a lot of organisations. I see many who I think are operating as EAs, who do not have any such title nor would want to be known as EAs. On the other hand, I meet people with EA in their title, whose sponsors themselves do not understand what EA is about.
Best regards,
Joseph George
+44 (0)78250 15480
http://uk.linkedin.com/in/josephg
On Jul 14, 7:42 pm, Bill wrote:
> Kirk,
> Excellent point and very valid as well. We must understand, however,
> that this subject is more than a personal training issues. This is a
> global and corporate training issue. Do a Dice, Monster, Indeed, etc.
> search for EA and you will get nigh 100% IT Architects that deal with
> something 'enterprise' (e.g. has an enterprise commitment,
> distribution, or effect). This is the information or mis-information
> that has been projected ever since the term 'architect' gained
> popularity.
> Let me explain my thoughts on an EA: An EA is a mini CxO type that is
> exists to work themselves out of a job by recreating, restructuring,
> and redefining the business. Many people think of this person as a
> 'super' project manager, but, there's much more to it. This person is
> part business-person, manager, executive, technologist, HR
> representative, project manager, and evangelist. At any given time
> there will be aspects of these positions being performed by the EA.
> Thus, this is where many see IT involvement of the EA. Organizations
> are still defining their technology and its integration with business
> and this is why technology finds its way, more often than not, into
> the EA portfolio. The EA works themselves out of a job by integrating
> the next phase of the vision and mission into the processes, people,
> and structures of the organization. They then move to the next phase
> and start over.
> The future of technology is full integration into the business of the
> organization. This is a transparency of technology that looks a lot> > > >> I'd like to get a feel for how many EA's there are in the world.
> like commoditization. I personally do not believe that it is a
> "Nicholas Carr" type of commoditization where technology is like a
> light switch and technologists need 'business smarts'. No, I think it
> is the other way around. The business will incorporate and utilize
> 'technology smarts' and what we know of IT now will be more fully
> automated, measurable, and structured for use/re-use (business people
> will need technology smarts as well as technologists needing business
> smarts).
> It is like any trend. Look at mass production. Automobile
> manufacturers (even fast food companies) went through similar efforts
> to restructure their services to accommodate mass production. Indoor
> plumbing, passenger airplanes, and a number of other trends in
> efficiency and productivity can be used to understand the EA movement.
> In any event, we are in the midst of a high flux period while
> technology grants increased capability to the EA. As such (and during
> such) we have a continual training process to perform in the
> organizations of the world. Thus, I agree with your previous
> statement; in the realization of each phase, everyone in an
> organization can be said to be doing enterprise architecture. And once
> you have an organization that is 'all in' on change and improvement,
> it is a correct statement. Each individual, having the vision and
> working towards it is helping to realize Enterprise Architecture. The
> difference is that this is the 'practice', or rather the effects of
> the practice, of Enterprise Architecture by the person (or people),
> the Enterprise Architect(s).
> So, after all of that... what do we do to clear up this confusion and
> fully define EA as well as define and differentiate E(IT)A and
> subsequent architects? These titles are not going away any time soon.
> On Jul 13, 5:11 pm, Rheinlander Kirk wrote:
> > You bring up a key point - IT is an enabler. In the APQC process model, IT is rightly an enabling support process activity - box 7.
> > EA deals with boxes 1-5, the core delivery of the product or service that is the revenue generation of the company. Yes, EA touches on all the other enabling processes, and IT is a very important one, but it is certainly not at the core of enterprise architecture.
> > The only time an enterprise architect is an IT architect, is when the core product or service the company produces is IT.
> > Unless you believe that the people that envisioned, designed, enabled, and practiced EA successfully for 25+ years know less about EA than you do??
> > So again, what are we counting??
> > On Jul 13, 2010, at 1:38 PM, maher dahdour wrote:
> > > How many times did we hear EA -as a role/not practice- in a non-IT organizations? Let me put it this way, where do we find an alignment of everything (People, Process.etc) in the enterprise with the strategy that has no automation and modernization (Goals) -technically using some sort of IT as an enabler-?
> > > Let us not associate discussion with reality.
> > > On Tue, Jul 13, 2010 at 3:37 PM, Derek Vandivere wrote:
> > > Well, we've got a couple hundred in the large consultancy I work for
> > > (the one that no longer employs Tiger Woods...).
> > > On Tue, Jul 13, 2010 at 3:45 PM, José Casimiro
> > > wrote:
> > > > Hi Gerald,
> > > > I think there must be at least 1000 enterprise architects. (world wide)
> > > > I consider an enterprise architect someone that tries to connect business
> > > > and computer processes and is a big expert in both. I guess that shouldn't
> > > > exist many more, because companies that have the "dimension" to have them,
> > > > probably do not feel the need to have them.
> > > > Regards,
> > > > JC
> > > > On 13 July 2010 11:04, Gerald wrote:
> > > >> I'd like to get a feel for how many EA's there are in the world.
> > > >> Feel free to define an "Enterprise Architect" any way you wish (just
> > > >> state what that assumption is, and please let's not get into arguments
> > > >> about what definition is right/wrong, for this exercise it doesn't
> > > >> matter).
> > > >> Obviously just looking for guestimates (unless you know of some
> > > >> research or stat's that have been collected) and interested on how you
> > > >> went about estimating this.
> > > >> Cheers, Gerald
> An EA is a mini CxO type that is
> exists to work themselves out of a job
I agree with you on the above. I have been saying that all along. Search this group for the discussion thread ("Architects" of the Enterprise?) among others.
The only people I see playing an EA role are the CxOs (to continue the American euphemism) within their remit. Anyone else is just applying the finishing touches or working out the finer details. And that means, an EA becomes a CxO representative involved in aspects lacking in the respective CxO. If an organisation were working as a well-oiled machine, it would not need an EA. Hence, an EA would be working themselves out of a job. But, the market evolves, the organisation evolves, the people/roles evolve. And so, the EA has a constant stream of inputs necessitating realigning the to-be system (organisation) and working out the impacts.
I don't think EA is about Frameworks, but they do help in terms of providing a structure and/or methodology.
Much of what is being touted about in this group as to-be EA is imho BA. Atleast that is what I see where Kirk is aiming - pure Business Architecture. I don't think you can disconnect a business (and its Business Architecture) from its operations (or Information Architecture and Technology Architecture).
> > > >> I'd like to get a feel for how many EA's there are in the world.
Back to the OP, I think Gerald would struggle to get any sort of valid statistics to justify any claim. I would even wonder about the purpose. The world is a large place with a lot of organisations. I see many who I think are operating as EAs, who do not have any such title nor would want to be known as EAs. On the other hand, I meet people with EA in their title, whose sponsors themselves do not understand what EA is about.
Best regards,
Joseph George
+44 (0)78250 15480
http://uk.linkedin.com/in/josephg
On Jul 14, 7:42 pm, Bill
> Kirk,
> Excellent point and very valid as well. We must understand, however,
> that this subject is more than a personal training issues. This is a
> global and corporate training issue. Do a Dice, Monster, Indeed, etc.
> search for EA and you will get nigh 100% IT Architects that deal with
> something 'enterprise' (e.g. has an enterprise commitment,
> distribution, or effect). This is the information or mis-information
> that has been projected ever since the term 'architect' gained
> popularity.
> Let me explain my thoughts on an EA: An EA is a mini CxO type that is
> exists to work themselves out of a job by recreating, restructuring,
> and redefining the business. Many people think of this person as a
> 'super' project manager, but, there's much more to it. This person is
> part business-person, manager, executive, technologist, HR
> representative, project manager, and evangelist. At any given time
> there will be aspects of these positions being performed by the EA.
> Thus, this is where many see IT involvement of the EA. Organizations
> are still defining their technology and its integration with business
> and this is why technology finds its way, more often than not, into
> the EA portfolio. The EA works themselves out of a job by integrating
> the next phase of the vision and mission into the processes, people,
> and structures of the organization. They then move to the next phase
> and start over.
> The future of technology is full integration into the business of the
> organization. This is a transparency of technology that looks a lot> > > >> I'd like to get a feel for how many EA's there are in the world.
> like commoditization. I personally do not believe that it is a
> "Nicholas Carr" type of commoditization where technology is like a
> light switch and technologists need 'business smarts'. No, I think it
> is the other way around. The business will incorporate and utilize
> 'technology smarts' and what we know of IT now will be more fully
> automated, measurable, and structured for use/re-use (business people
> will need technology smarts as well as technologists needing business
> smarts).
> It is like any trend. Look at mass production. Automobile
> manufacturers (even fast food companies) went through similar efforts
> to restructure their services to accommodate mass production. Indoor
> plumbing, passenger airplanes, and a number of other trends in
> efficiency and productivity can be used to understand the EA movement.
> In any event, we are in the midst of a high flux period while
> technology grants increased capability to the EA. As such (and during
> such) we have a continual training process to perform in the
> organizations of the world. Thus, I agree with your previous
> statement; in the realization of each phase, everyone in an
> organization can be said to be doing enterprise architecture. And once
> you have an organization that is 'all in' on change and improvement,
> it is a correct statement. Each individual, having the vision and
> working towards it is helping to realize Enterprise Architecture. The
> difference is that this is the 'practice', or rather the effects of
> the practice, of Enterprise Architecture by the person (or people),
> the Enterprise Architect(s).
> So, after all of that... what do we do to clear up this confusion and
> fully define EA as well as define and differentiate E(IT)A and
> subsequent architects? These titles are not going away any time soon.
> On Jul 13, 5:11 pm, Rheinlander Kirk
> > You bring up a key point - IT is an enabler. In the APQC process model, IT is rightly an enabling support process activity - box 7.
> > EA deals with boxes 1-5, the core delivery of the product or service that is the revenue generation of the company. Yes, EA touches on all the other enabling processes, and IT is a very important one, but it is certainly not at the core of enterprise architecture.
> > The only time an enterprise architect is an IT architect, is when the core product or service the company produces is IT.
> > Unless you believe that the people that envisioned, designed, enabled, and practiced EA successfully for 25+ years know less about EA than you do??
> > So again, what are we counting??
> > On Jul 13, 2010, at 1:38 PM, maher dahdour wrote:
> > > How many times did we hear EA -as a role/not practice- in a non-IT organizations? Let me put it this way, where do we find an alignment of everything (People, Process.etc) in the enterprise with the strategy that has no automation and modernization (Goals) -technically using some sort of IT as an enabler-?
> > > Let us not associate discussion with reality.
> > > On Tue, Jul 13, 2010 at 3:37 PM, Derek Vandivere
> > > Well, we've got a couple hundred in the large consultancy I work for
> > > (the one that no longer employs Tiger Woods...).
> > > On Tue, Jul 13, 2010 at 3:45 PM, José Casimiro
> > >
> > > > Hi Gerald,
> > > > I think there must be at least 1000 enterprise architects. (world wide)
> > > > I consider an enterprise architect someone that tries to connect business
> > > > and computer processes and is a big expert in both. I guess that shouldn't
> > > > exist many more, because companies that have the "dimension" to have them,
> > > > probably do not feel the need to have them.
> > > > Regards,
> > > > JC
> > > > On 13 July 2010 11:04, Gerald
> > > >> I'd like to get a feel for how many EA's there are in the world.
> > > >> Feel free to define an "Enterprise Architect" any way you wish (just
> > > >> state what that assumption is, and please let's not get into arguments
> > > >> about what definition is right/wrong, for this exercise it doesn't
> > > >> matter).
> > > >> Obviously just looking for guestimates (unless you know of some
> > > >> research or stat's that have been collected) and interested on how you
> > > >> went about estimating this.
> > > >> Cheers, Gerald
Strategic turnaround case-study: Microsoft
Innovation challenges
Rob 83-93
- per capita ability to get effective innovations into the market is doubful
- four core points
1. PC Software Centricity: core business
2. Post-PC World: stuck in the past
3. Monopoly Economics and Culture: un-viable monopoly business
4. Leadership: culture
Kanji 02-05
Past:
Now:
- Trends are shorter
-
Visionless Leadership
- loyalty over quality - compromising excellence, slow death!
- fretful reaction to challengers
- "Can you think of any other tech firm where the CEO could bungle the company's main product and still keep his job?"
Bill Gates:
- moved on now - "saving the world is more important than saving microsoft"
- innovative vision
- negative energy - "moved mountains to crush netscape"
- "his actions weren't very admirable"
- "there was never a lot to like about Bill Gates the businessman"
Rob 83-93
- per capita ability to get effective innovations into the market is doubful
- four core points
1. PC Software Centricity: core business
2. Post-PC World: stuck in the past
3. Monopoly Economics and Culture: un-viable monopoly business
4. Leadership: culture
Kanji 02-05
Past:
Now:
- Trends are shorter
-
Visionless Leadership
- loyalty over quality - compromising excellence, slow death!
- fretful reaction to challengers
- "Can you think of any other tech firm where the CEO could bungle the company's main product and still keep his job?"
Bill Gates:
- moved on now - "saving the world is more important than saving microsoft"
- innovative vision
- negative energy - "moved mountains to crush netscape"
- "his actions weren't very admirable"
- "there was never a lot to like about Bill Gates the businessman"
Finance Director
tags
finance
Financial leaders discuss their level of oversight and share the most important issues from their experiences in the CFO role:
"Just make sure your skill level meets the job competency levels the company desires. Do a Dunn & Bradstreet report on their performance. Make no mistake about it — large publicly traded companies are all about meeting financial performance goals, and if not, they fire someone."
"A CFO manages the organization's strategic value and that value is enhanced with its influence on HR, IT, risk management and insurance. Such functions should always report to the CFO, as they then bring the external strategy with customers in alignment with internal set up through administration and teams."
"For the CFO transitioning from a private company to a public one, the major change is that you become a high profile spokesperson for the public company — very different than a private company environment."
"...you are connected to every area of the company; your influence is felt everywhere."
"Just make sure your skill level meets the job competency levels the company desires. Do a Dunn & Bradstreet report on their performance. Make no mistake about it — large publicly traded companies are all about meeting financial performance goals, and if not, they fire someone."
"A CFO manages the organization's strategic value and that value is enhanced with its influence on HR, IT, risk management and insurance. Such functions should always report to the CFO, as they then bring the external strategy with customers in alignment with internal set up through administration and teams."
"For the CFO transitioning from a private company to a public one, the major change is that you become a high profile spokesperson for the public company — very different than a private company environment."
"...you are connected to every area of the company; your influence is felt everywhere."
Strategy by Michael Porter
tags
strategy
At the World Innovation Forum, Michael Porter shared his perspectives on what he knows best:
What is strategy? "It's a complete and unique value proposition for a specific set of customers that distinguishes you from your competitors. You need renewed clarity of the fundamental purpose of your company and what makes you different."
What is innovation? "Non-incremental improvements in productivity, in the value chain or the product itself. Incremental improvement is something that can be done in predictable process. Innovation is something where you see a new combination or go in a different direction. The failures of innovation are that you can do something but it is not valuable, or you can do it but it is not affordable."
Is there good innovation and bad innovation? "Corporations have to examine what they do and find out whether they're creating real value with their innovations. Are the innovations we are making practical, and can they be delivered at a reasonable cost? If an innovation fails one of these tests, it is more likely a bad innovation."
What is strategy? "It's a complete and unique value proposition for a specific set of customers that distinguishes you from your competitors. You need renewed clarity of the fundamental purpose of your company and what makes you different."
What is innovation? "Non-incremental improvements in productivity, in the value chain or the product itself. Incremental improvement is something that can be done in predictable process. Innovation is something where you see a new combination or go in a different direction. The failures of innovation are that you can do something but it is not valuable, or you can do it but it is not affordable."
Is there good innovation and bad innovation? "Corporations have to examine what they do and find out whether they're creating real value with their innovations. Are the innovations we are making practical, and can they be delivered at a reasonable cost? If an innovation fails one of these tests, it is more likely a bad innovation."
British Budget 2010
tags
economy
The role of the Budget is to provide an update on the state of the economy and the public finances and to present new forecasts for each, to set out the Government's economic and fiscal objectives, to report on the progress the Government has made toward achieving its objectives, and to set out the further steps the Government is taking to meet them.
The Budget is the major financial and economic statement made each year by the Chancellor of the Exchequer to the Parliament. A guide to the Budget, including a list of all Chancellors since World War II is available on this website:
http://hm-treasury.gov.uk/budget.htm.
I'll try to update this post with my perspective of the budget.
The Budget is the major financial and economic statement made each year by the Chancellor of the Exchequer to the Parliament. A guide to the Budget, including a list of all Chancellors since World War II is available on this website:
http://hm-treasury.gov.uk/budget.htm.
I'll try to update this post with my perspective of the budget.
The African Runner
tags
philosophy
Every morning, a gazelle wakes up knowing that it must run faster than the fastest lion, or die.
Every morning, a lion wakes up knowing that it must run faster than the slowest gazelle, or starve.
- excerpt from an African Proverb
Every morning, a lion wakes up knowing that it must run faster than the slowest gazelle, or starve.
- excerpt from an African Proverb
Tool first or Purpose first for EA
Quite possibly... Should I have bought a (flat-pack?) shed first, and then go shopping for the tools required? Or, should I buy the tools first, and then go shopping for my d-i-y shed?
Note: We are not discussing whether tools are useful or should we use tools? Tools are *definitely* useful and we *should* use appropriate tools, when required.
Best regards,
Joseph
On Jun 15, 7:15 am, "alan lloyd" wrote:
> Great one Ken .. sounds like we are of the same vintage..
> I remember when my dad used to build garden sheds with a hand saw and a
> hammer..
> The last shed I put up was 1000 times more sophisticated than that i.e had
> electric roller doors.. and the tools were different too - a lot of them for
> some reason had wires with mains plugs on them :-)
> Could one say - that without an understanding of the tools available -
> there would similar lack of understanding of the material at hand and the
> processes to use them?
> -----Original Message-----
> From: the-enterprise-architecture-network@googlegroups.com
> [mailto:the-enterprise-architecture-network@googlegroups.com] On Behalf Of
> Ken Orr
> Sent: Monday, 14 June 2010 5:09 AM
> To: The Enterprise Architecture Network
> Subject: Re: Tool first or Purpose first for EA
> I can also remember doing EA before tools. Indeed, I remember doing
> programming
> when the only tools were assemblers and core dumps, but I can't
> imagine going
> back to that point even though I saw some marvelous programs developed
> using
> only primitive tools, blackboards, paper and pencil and brain power.
> The point about tools is that there are certain problems dealing with
> scale that cannot
> really be attacked without tools, tools that those of us "doing EA"
> invented for
> the express purpose of "doing EA better".
> Ken Orr
> On Jun 12, 10:53 am, Glen wrote:
> > Amazingly enough, we created and implemented EAs before there were any
> > "tools". I created my first EA in the mid 80's and there were many
> > people earlier than I. We had word processing and some rudimentary
> > drawing capabilities plus pencil and paper. This didn't stop us from
> > being effective and I'm not sure it was really all that inefficient.
> > It certainly didn't line the pockets of the tool vendors. Most of
> > the work was and still is getting the EA adopted and the systems
> > (business and technical) compliant.
> > On May 18, 11:06 am, Eswar Ganesan wrote:
> > > Hi All,
> > > What is the best practice of developing an Enterprise Architecture -
> > > "Architecture Strategy first and Tool second" or "Tool First and
> > > Architecture Strategy second".
> > > I have seen a situation wherein the tool has been bought first and then
> few
> > > people are sitting around with the tool and identify that the tool can
> do
> > > process modeling, data modeling, application landscaping and technology
> > > collaboration diagram etc - so the approach for EA has taken shape such
> that
> > > - okay, these are the 15 templates that are available in the tool and
> lets
> > > make it a mandate across the company so that if someone has to model
> some
> > > diagram around this 15 template then they have to come to this team
> which
> > > can help doing this. Is this EA?
> > > In my opinion, EA design and strategy - the motivation element comes
> first -
> > > make it a case that the purpose, framework and approach for EA defined
> and
> > > then decide on tool and approaches to deliver architectural
> deliverables.
> > > What do you fellow architects comment on this, thanks,
> > > Regards,
> > > Eswar
Note: We are not discussing whether tools are useful or should we use tools? Tools are *definitely* useful and we *should* use appropriate tools, when required.
Best regards,
Joseph
On Jun 15, 7:15 am, "alan lloyd"
> Great one Ken .. sounds like we are of the same vintage..
> I remember when my dad used to build garden sheds with a hand saw and a
> hammer..
> The last shed I put up was 1000 times more sophisticated than that i.e had
> electric roller doors.. and the tools were different too - a lot of them for
> some reason had wires with mains plugs on them :-)
> Could one say - that without an understanding of the tools available -
> there would similar lack of understanding of the material at hand and the
> processes to use them?
> -----Original Message-----
> From: the-enterprise-architecture-network@googlegroups.com
> [mailto:the-enterprise-architecture-network@googlegroups.com] On Behalf Of
> Ken Orr
> Sent: Monday, 14 June 2010 5:09 AM
> To: The Enterprise Architecture Network
> Subject: Re: Tool first or Purpose first for EA
> I can also remember doing EA before tools. Indeed, I remember doing
> programming
> when the only tools were assemblers and core dumps, but I can't
> imagine going
> back to that point even though I saw some marvelous programs developed
> using
> only primitive tools, blackboards, paper and pencil and brain power.
> The point about tools is that there are certain problems dealing with
> scale that cannot
> really be attacked without tools, tools that those of us "doing EA"
> invented for
> the express purpose of "doing EA better".
> Ken Orr
> On Jun 12, 10:53 am, Glen
> > Amazingly enough, we created and implemented EAs before there were any
> > "tools". I created my first EA in the mid 80's and there were many
> > people earlier than I. We had word processing and some rudimentary
> > drawing capabilities plus pencil and paper. This didn't stop us from
> > being effective and I'm not sure it was really all that inefficient.
> > It certainly didn't line the pockets of the tool vendors. Most of
> > the work was and still is getting the EA adopted and the systems
> > (business and technical) compliant.
> > On May 18, 11:06 am, Eswar Ganesan
> > > Hi All,
> > > What is the best practice of developing an Enterprise Architecture -
> > > "Architecture Strategy first and Tool second" or "Tool First and
> > > Architecture Strategy second".
> > > I have seen a situation wherein the tool has been bought first and then
> few
> > > people are sitting around with the tool and identify that the tool can
> do
> > > process modeling, data modeling, application landscaping and technology
> > > collaboration diagram etc - so the approach for EA has taken shape such
> that
> > > - okay, these are the 15 templates that are available in the tool and
> lets
> > > make it a mandate across the company so that if someone has to model
> some
> > > diagram around this 15 template then they have to come to this team
> which
> > > can help doing this. Is this EA?
> > > In my opinion, EA design and strategy - the motivation element comes
> first -
> > > make it a case that the purpose, framework and approach for EA defined
> and
> > > then decide on tool and approaches to deliver architectural
> deliverables.
> > > What do you fellow architects comment on this, thanks,
> > > Regards,
> > > Eswar
The Power of One
tags
virtual
Integrated End-to-End Virtualisation
Virtualisation gives you the power of one. One instance of each desktop OS. One copy of each application. One image of each server workload. Managed centrally and assembled dynamically at runtime. Delivered as a secure, personalised, on-demand service.
Less is more...
http://simplicityispower.citrix.com/
Virtualisation gives you the power of one. One instance of each desktop OS. One copy of each application. One image of each server workload. Managed centrally and assembled dynamically at runtime. Delivered as a secure, personalised, on-demand service.
Less is more...
http://simplicityispower.citrix.com/
The 5 Ws and 1 H
tags
tea.net
The courage of thinking about the 5Ws and 1H
What When Where Who Why
How
We don't start with "The How"!
What When Where Who Why
How
We don't start with "The How"!
Integrating EA Mgmt and Technical Frameworks
AOGEA Ottawa-Gatineau Chapter
EA Seminar - 29 Mar 1010
Integrating Enterprise Architecture Management and Technical Frameworks
Presented by:
Lynn Wallace, Sr Information Architect, Canada Revenue Agency
Robert (Bob) Weisman, CEO, Build The Vision Inc.
EA Seminar - 29 Mar 1010
Integrating Enterprise Architecture Management and Technical Frameworks
Presented by:
Lynn Wallace, Sr Information Architect, Canada Revenue Agency
Robert (Bob) Weisman, CEO, Build The Vision Inc.
Tool first or Purpose first for EA
Ken,
> EA tools are not a question of whether but when, and the when is when
> you know enough to use them.
I don't think we are debating whether a tool is needed or what that tool should be. We are specifically discussing only "the when" aspect.
You do say
> First you need a dynamic methodology, then you
> need training, tools and expertise to
> support it.
I kind of agree with you above about the first. But I would suggest, first you need an EA Vision to start. This delivers some goals to target, i.e. reduce cost, increase agility, or increase capability, etc. All the other steps follow later, perhaps in different orders depending on the organisation maturity and its readiness. I completely agree with Peter Hunsberger on his last posts.
> YOU SIMPLY CAN'T DO "REAL EA" WITHOUT TOOLS, INDUSTRIAL
> GRADE TOOLS!
Hmmm... What is "REAL EA"? Even EAs can't seem to agree... :-)
And, I see no point in buying "INDUSTRIAL GRADE TOOLS", if the organisation simply cannot afford it, or the people to use it, i.e. does not have capable EAs or other personnel to support this amazing tool. An EA tool is only good enough if everyone who are supposed to populate it, are diligent and skilled enough with this tool. Else, the TCO would result in a white elephant and another shelfware.
If the organisation can afford a good tool, has trained EAs and all other relevant analysts in this particular tool, then it is probably ready to use this tool. If this is the case, it better have supportive management ready to drive forward the resultant EA delivery and targets. Otherwise, all these efforts would just generate another business process and red-tapes hampering business agility.
To end my £0.02, I would say, have capable people in place, before you get capable tools. Who would identify which tool is capable? When/How would this capable tool become beneficial?
Best regards,
Joseph
On May 29, 5:40 pm, Ken Orr wrote:
> Every once in while people get heated about the wrong question. The
> statement that some organization
> “started EA before they started with the tools” is kind of
> meaningless. What's missing is the idea of a
> workable methodology. First you need a dynamic methodology, then you
> need training, tools and expertise to
> support it. YOU SIMPLY CAN'T DO "REAL EA" WITHOUT TOOLS, INDUSTRIAL
> GRADE TOOLS!" Sure you
> can use Visio to draw pictures, but and EA database is not just a set
> of pictures done one time,it is a set
> of pictures that support an EA Roadmap that are constantly updated.
> One of the core problems with REAL EA is that the problems are so
> complex that you need special tools to
> address just the interactions between systems or the numbers of
> individual data tables. If you select tools too
> early, however, there is a good chance that the organization will not
> really understand what the requirements
> are and end up trying to get the cheapest solution...bad idea.
> EA tools are not a question of whether but when, and the when is when
> you know enough to use them.
> Ken
> On May 26, 3:05 am, Joseph George southern.co.uk> wrote:
> > Kevin,
> > > Not sure what “started EA before they started with the tools.” means -
> > > but as I understood it (after sitting through the presentation) they
> > > only way they started was to buy a tool, figure out a good question
> > > they wanted to answer that would give a big return (application
> > > portfolio rationalisation), populated the tool with the data required,
> > > made some changes, save d a lot of money, modelled some more, etc,
> > > etc.
> > Hmmm... that sounds like a fool with a tool approach. We could apply
> > this same principle to any (not necessarily EA) tool and start a
> > business model around that tool, viz. "buy a tool, figure out a good
> > question they wanted to answer that would give a big return, populated
> > the tool with the data required, made some changes, save d a lot of
> > money, modelled some more, etc, etc." Et Voila, I've got a new
> > business case. Let us buy a hammer (or whatever the latest jazzy thing
> > the advertising industry is throwing at us), figure out a good
> > question... that would give a big return,... etc etc.
> > But further down your post, you answer exactly what I meant. You
> > probably figured that yourself
> > > Which is why I asked Colin Birchenall after the presentation.
> > And the answer contains the EA approach and the tool was part of their
> > solution. Purrfect!
> > > to start modelling stuff, so we can
> > > understand stuff, so we can kill stuff where we don’t need it, and
> > > strengthen stuff where we do”
> > And what a brilliant way to gain buy-in from the business owners:
> > > the only way we can work with you and
> > > generate a return for all is to
> > I like this approach. Either we agree on a clear approach and work
> > together and generate a return for all. Or we can't generate a return
> > and won't work with you! Any waffling rhetoric about fluffy stuff just
> > muddies the water for the sponsors and disengage them.
> > Kind regards,
> > Joseph
> > On May 24, 4:01 pm, "Kevin (PragmaticEA.com) Smith"
> > wrote:
> > > @Joseph: “However, I would venture to say from the example he gives
> > > that they started EA before they started with the tools. All it means
> > > is that they started using the tool, before they had a complete EA
> > > vision populated.”
> > > Not sure what “started EA before they started with the tools.” means -
> > > but as I understood it (after sitting through the presentation) they
> > > only way they started was to buy a tool, figure out a good question
> > > they wanted to answer that would give a big return (application
> > > portfolio rationalisation), populated the tool with the data required,
> > > made some changes, save d a lot of money, modelled some more, etc,
> > > etc.
> > > They started at the application /infrastructure level then moved up
> > > into solution architecture, then project portfolio then strategy.
> > > The point being they did stuff that saved money.
> > > The question, of course is…
> > > “OK - but you needed a mandate/money etc to buy the tool, have some
> > > training, and the people to do some modelling etc right? So how did
> > > you get the mandate/money ?”
> > > Which is why I asked Colin Birchenall after the presentation.
> > > Hi answer was - “Yes, exactly right - the catalyst was the formation
> > > of the LLP between Serco and Glasgow City Council. Serco had basically
> > > said, OK - you want us to be in partnership with you in terms of
> > > provision of IT? = no problem - the only way we can work with you and
> > > generate a return for all is to start modelling stuff, so we can
> > > understand stuff, so we can kill stuff where we don’t need it, and
> > > strengthen stuff where we do”
> > > Colin also agreed that what they had done was not rocket science and
> > > simply common sense and that many many organisations have many people
> > > who already know what should be done and how it should be done but
> > > they don’t get the remit/budget/mandate to do anything.
> > > Which is why I have started thinking that the best way to get
> > > organisations to adopt EA is to marry the education and awareness
> > > approach with a catalyst approach. There are many…
> > > - Mergers & Acquisitions
> > > - Business Unit Consolidation
> > > - Introduction of New Products, Services or Lines of Business
> > > - Outsourcing a Business Function
> > > - Divesting a line of Business
> > > - Operational Cost Reduction
> > > - Business Transformation
> > > - Building Relocation
> > > - Strategic Planning
> > > - Increase Business Agility, Efficiency and Effectiveness
> > > - Streamlining Business Processes
> > > - Consolidation of Suppliers, Technologies or Applications
> > > - Business Process Management
> > > - Business Process Re-engineering
> > > - Off shoring
> > > - Market/Shareholder Pressure
> > > @Joseph: “, EA …..is an iterative process. You could start anywhere in
> > > this circle”
> > > Sort of. some things you can some things you cant; For example, you
> > > can just start modelling stuff before buying a proper tool, however
> > > you can’t start doing governance using principles (operate) until you
> > > a) have agreed what they are and b) made the changes in the
> > > organisation required to operate them (Implement)
> > > @Joseph: “Just because you have an EA team using an EA tool, doesn't
> > > mean you are actually performing EA.”
> > > I would say yes and no.
> > > My higher level view is that EA is generally about strategic planning,
> > > modeeling and governance.
> > > Based on this, I would say that 99.9999% of organisations are already
> > > “doing” EA. They already do strategic planning (it may be terrible),
> > > they already do modelling (it may be terrible) they already do
> > > governance (it may be terrible).
> > > They may do everything terribly, but they still have an EA and they
> > > still do EA.
> > > If you don’t use a project management methodology (e.g. Prince2, MSP)
> > > does this mean you don’t do project management? No.
> > > Frameworks help people to do what they are doing in a more efficient,
> > > better, structured way.
> > > EA is no different to Prince, MSP, Six Sigma, LEAN, ITIL, COBIT, etc
> > > etc etc.
> > > They are all frameworks/.methodologies/methods for improving thngs.
> > > They just scratch different itches.
> > > @Joseph: “But, all your efforts would be towards populating the as-is
> > > with lower-
...
read more »
> EA tools are not a question of whether but when, and the when is when
> you know enough to use them.
I don't think we are debating whether a tool is needed or what that tool should be. We are specifically discussing only "the when" aspect.
You do say
> First you need a dynamic methodology, then you
> need training, tools and expertise to
> support it.
I kind of agree with you above about the first. But I would suggest, first you need an EA Vision to start. This delivers some goals to target, i.e. reduce cost, increase agility, or increase capability, etc. All the other steps follow later, perhaps in different orders depending on the organisation maturity and its readiness. I completely agree with Peter Hunsberger on his last posts.
> YOU SIMPLY CAN'T DO "REAL EA" WITHOUT TOOLS, INDUSTRIAL
> GRADE TOOLS!
Hmmm... What is "REAL EA"? Even EAs can't seem to agree... :-)
And, I see no point in buying "INDUSTRIAL GRADE TOOLS", if the organisation simply cannot afford it, or the people to use it, i.e. does not have capable EAs or other personnel to support this amazing tool. An EA tool is only good enough if everyone who are supposed to populate it, are diligent and skilled enough with this tool. Else, the TCO would result in a white elephant and another shelfware.
If the organisation can afford a good tool, has trained EAs and all other relevant analysts in this particular tool, then it is probably ready to use this tool. If this is the case, it better have supportive management ready to drive forward the resultant EA delivery and targets. Otherwise, all these efforts would just generate another business process and red-tapes hampering business agility.
To end my £0.02, I would say, have capable people in place, before you get capable tools. Who would identify which tool is capable? When/How would this capable tool become beneficial?
Best regards,
Joseph
On May 29, 5:40 pm, Ken Orr
> Every once in while people get heated about the wrong question. The
> statement that some organization
> “started EA before they started with the tools” is kind of
> meaningless. What's missing is the idea of a
> workable methodology. First you need a dynamic methodology, then you
> need training, tools and expertise to
> support it. YOU SIMPLY CAN'T DO "REAL EA" WITHOUT TOOLS, INDUSTRIAL
> GRADE TOOLS!" Sure you
> can use Visio to draw pictures, but and EA database is not just a set
> of pictures done one time,it is a set
> of pictures that support an EA Roadmap that are constantly updated.
> One of the core problems with REAL EA is that the problems are so
> complex that you need special tools to
> address just the interactions between systems or the numbers of
> individual data tables. If you select tools too
> early, however, there is a good chance that the organization will not
> really understand what the requirements
> are and end up trying to get the cheapest solution...bad idea.
> EA tools are not a question of whether but when, and the when is when
> you know enough to use them.
> Ken
> On May 26, 3:05 am, Joseph George
> > Kevin,
> > > Not sure what “started EA before they started with the tools.” means -
> > > but as I understood it (after sitting through the presentation) they
> > > only way they started was to buy a tool, figure out a good question
> > > they wanted to answer that would give a big return (application
> > > portfolio rationalisation), populated the tool with the data required,
> > > made some changes, save d a lot of money, modelled some more, etc,
> > > etc.
> > Hmmm... that sounds like a fool with a tool approach. We could apply
> > this same principle to any (not necessarily EA) tool and start a
> > business model around that tool, viz. "buy a tool, figure out a good
> > question they wanted to answer that would give a big return, populated
> > the tool with the data required, made some changes, save d a lot of
> > money, modelled some more, etc, etc." Et Voila, I've got a new
> > business case. Let us buy a hammer (or whatever the latest jazzy thing
> > the advertising industry is throwing at us), figure out a good
> > question... that would give a big return,... etc etc.
> > But further down your post, you answer exactly what I meant. You
> > probably figured that yourself
> > > Which is why I asked Colin Birchenall after the presentation.
> > And the answer contains the EA approach and the tool was part of their
> > solution. Purrfect!
> > > to start modelling stuff, so we can
> > > understand stuff, so we can kill stuff where we don’t need it, and
> > > strengthen stuff where we do”
> > And what a brilliant way to gain buy-in from the business owners:
> > > the only way we can work with you and
> > > generate a return for all is to
> > I like this approach. Either we agree on a clear approach and work
> > together and generate a return for all. Or we can't generate a return
> > and won't work with you! Any waffling rhetoric about fluffy stuff just
> > muddies the water for the sponsors and disengage them.
> > Kind regards,
> > Joseph
> > On May 24, 4:01 pm, "Kevin (PragmaticEA.com) Smith"
> >
> > > @Joseph: “However, I would venture to say from the example he gives
> > > that they started EA before they started with the tools. All it means
> > > is that they started using the tool, before they had a complete EA
> > > vision populated.”
> > > Not sure what “started EA before they started with the tools.” means -
> > > but as I understood it (after sitting through the presentation) they
> > > only way they started was to buy a tool, figure out a good question
> > > they wanted to answer that would give a big return (application
> > > portfolio rationalisation), populated the tool with the data required,
> > > made some changes, save d a lot of money, modelled some more, etc,
> > > etc.
> > > They started at the application /infrastructure level then moved up
> > > into solution architecture, then project portfolio then strategy.
> > > The point being they did stuff that saved money.
> > > The question, of course is…
> > > “OK - but you needed a mandate/money etc to buy the tool, have some
> > > training, and the people to do some modelling etc right? So how did
> > > you get the mandate/money ?”
> > > Which is why I asked Colin Birchenall after the presentation.
> > > Hi answer was - “Yes, exactly right - the catalyst was the formation
> > > of the LLP between Serco and Glasgow City Council. Serco had basically
> > > said, OK - you want us to be in partnership with you in terms of
> > > provision of IT? = no problem - the only way we can work with you and
> > > generate a return for all is to start modelling stuff, so we can
> > > understand stuff, so we can kill stuff where we don’t need it, and
> > > strengthen stuff where we do”
> > > Colin also agreed that what they had done was not rocket science and
> > > simply common sense and that many many organisations have many people
> > > who already know what should be done and how it should be done but
> > > they don’t get the remit/budget/mandate to do anything.
> > > Which is why I have started thinking that the best way to get
> > > organisations to adopt EA is to marry the education and awareness
> > > approach with a catalyst approach. There are many…
> > > - Mergers & Acquisitions
> > > - Business Unit Consolidation
> > > - Introduction of New Products, Services or Lines of Business
> > > - Outsourcing a Business Function
> > > - Divesting a line of Business
> > > - Operational Cost Reduction
> > > - Business Transformation
> > > - Building Relocation
> > > - Strategic Planning
> > > - Increase Business Agility, Efficiency and Effectiveness
> > > - Streamlining Business Processes
> > > - Consolidation of Suppliers, Technologies or Applications
> > > - Business Process Management
> > > - Business Process Re-engineering
> > > - Off shoring
> > > - Market/Shareholder Pressure
> > > @Joseph: “, EA …..is an iterative process. You could start anywhere in
> > > this circle”
> > > Sort of. some things you can some things you cant; For example, you
> > > can just start modelling stuff before buying a proper tool, however
> > > you can’t start doing governance using principles (operate) until you
> > > a) have agreed what they are and b) made the changes in the
> > > organisation required to operate them (Implement)
> > > @Joseph: “Just because you have an EA team using an EA tool, doesn't
> > > mean you are actually performing EA.”
> > > I would say yes and no.
> > > My higher level view is that EA is generally about strategic planning,
> > > modeeling and governance.
> > > Based on this, I would say that 99.9999% of organisations are already
> > > “doing” EA. They already do strategic planning (it may be terrible),
> > > they already do modelling (it may be terrible) they already do
> > > governance (it may be terrible).
> > > They may do everything terribly, but they still have an EA and they
> > > still do EA.
> > > If you don’t use a project management methodology (e.g. Prince2, MSP)
> > > does this mean you don’t do project management? No.
> > > Frameworks help people to do what they are doing in a more efficient,
> > > better, structured way.
> > > EA is no different to Prince, MSP, Six Sigma, LEAN, ITIL, COBIT, etc
> > > etc etc.
> > > They are all frameworks/.methodologies/methods for improving thngs.
> > > They just scratch different itches.
> > > @Joseph: “But, all your efforts would be towards populating the as-is
> > > with lower-
...
read more »
Tool first or Purpose first for EA
A scenario comes to mind -
A man wants to start a business. So, he goes downtown to the city centre and rents a shop in a prime location. He puts up a nice banner outside, and enters his shop... and starts thinking. What should his business be?
Next he goes outside and looks at some of the other shops. He finds some gadgets which take his fancy. He buys those from his friendly neighbouring shops, and brings those tools back to his shop. He starts thinking again... What should his business be?
Is this where an EA enters the scenario??
Best regards,
Joseph
A man wants to start a business. So, he goes downtown to the city centre and rents a shop in a prime location. He puts up a nice banner outside, and enters his shop... and starts thinking. What should his business be?
Next he goes outside and looks at some of the other shops. He finds some gadgets which take his fancy. He buys those from his friendly neighbouring shops, and brings those tools back to his shop. He starts thinking again... What should his business be?
Is this where an EA enters the scenario??
Best regards,
Joseph
SOA Best Practices @Gartner
I attended a Gartner briefing called "SOA Best Practices - How To Use It To Make A Difference" at their EMEA HQ in Egham.
Of the three presentations,
(1) was very useful
(2) was all about development, and not much to do with SOA
(3) was all about file transfers, and not relevant at all
Of the three presentations,
(1) was very useful
(2) was all about development, and not much to do with SOA
(3) was all about file transfers, and not relevant at all
Tool first or Purpose first for EA
Kevin,
> Not sure what “started EA before they started with the tools.” means -
> but as I understood it (after sitting through the presentation) they
> only way they started was to buy a tool, figure out a good question
> they wanted to answer that would give a big return (application
> portfolio rationalisation), populated the tool with the data required,
> made some changes, save d a lot of money, modelled some more, etc,
> etc.
Hmmm... that sounds like a fool with a tool approach. We could apply this same principle to any (not necessarily EA) tool and start a business model around that tool, viz. "buy a tool, figure out a good question they wanted to answer that would give a big return, populated the tool with the data required, made some changes, save d a lot of money, modelled some more, etc, etc." Et Voila, I've got a new business case. Let us buy a hammer (or whatever the latest jazzy thing the advertising industry is throwing at us), figure out a good question... that would give a big return,... etc etc.
But further down your post, you answer exactly what I meant. You probably figured that yourself
> Which is why I asked Colin Birchenall after the presentation.
And the answer contains the EA approach and the tool was part of their solution. Purrfect!
> to start modelling stuff, so we can
> understand stuff, so we can kill stuff where we don’t need it, and
> strengthen stuff where we do”
And what a brilliant way to gain buy-in from the business owners:
> the only way we can work with you and
> generate a return for all is to
I like this approach. Either we agree on a clear approach and work together and generate a return for all. Or we can't generate a return and won't work with you! Any waffling rhetoric about fluffy stuff just muddies the water for the sponsors and disengage them.
Kind regards,
Joseph
On May 24, 4:01 pm, "Kevin (PragmaticEA.com) Smith"
wrote:
> @Joseph: “However, I would venture to say from the example he gives
> that they started EA before they started with the tools. All it means
> is that they started using the tool, before they had a complete EA
> vision populated.”
> Not sure what “started EA before they started with the tools.” means -
> but as I understood it (after sitting through the presentation) they
> only way they started was to buy a tool, figure out a good question
> they wanted to answer that would give a big return (application
> portfolio rationalisation), populated the tool with the data required,
> made some changes, save d a lot of money, modelled some more, etc,
> etc.
> They started at the application /infrastructure level then moved up
> into solution architecture, then project portfolio then strategy.
> The point being they did stuff that saved money.
> The question, of course is…
> “OK - but you needed a mandate/money etc to buy the tool, have some
> training, and the people to do some modelling etc right? So how did
> you get the mandate/money ?”
> Which is why I asked Colin Birchenall after the presentation.
> Hi answer was - “Yes, exactly right - the catalyst was the formation
> of the LLP between Serco and Glasgow City Council. Serco had basically
> said, OK - you want us to be in partnership with you in terms of
> provision of IT? = no problem - the only way we can work with you and
> generate a return for all is to start modelling stuff, so we can
> understand stuff, so we can kill stuff where we don’t need it, and
> strengthen stuff where we do”
> Colin also agreed that what they had done was not rocket science and
> simply common sense and that many many organisations have many people
> who already know what should be done and how it should be done but
> they don’t get the remit/budget/mandate to do anything.
> Which is why I have started thinking that the best way to get
> organisations to adopt EA is to marry the education and awareness
> approach with a catalyst approach. There are many…
> - Mergers & Acquisitions
> - Business Unit Consolidation
> - Introduction of New Products, Services or Lines of Business
> - Outsourcing a Business Function
> - Divesting a line of Business
> - Operational Cost Reduction
> - Business Transformation
> - Building Relocation
> - Strategic Planning
> - Increase Business Agility, Efficiency and Effectiveness
> - Streamlining Business Processes
> - Consolidation of Suppliers, Technologies or Applications
> - Business Process Management
> - Business Process Re-engineering
> - Off shoring
> - Market/Shareholder Pressure
> @Joseph: “, EA …..is an iterative process. You could start anywhere in
> this circle”
> Sort of. some things you can some things you cant; For example, you
> can just start modelling stuff before buying a proper tool, however
> you can’t start doing governance using principles (operate) until you
> a) have agreed what they are and b) made the changes in the
> organisation required to operate them (Implement)
> @Joseph: “Just because you have an EA team using an EA tool, doesn't
> mean you are actually performing EA.”
> I would say yes and no.
> My higher level view is that EA is generally about strategic planning,
> modeeling and governance.
> Based on this, I would say that 99.9999% of organisations are already
> “doing” EA. They already do strategic planning (it may be terrible),
> they already do modelling (it may be terrible) they already do
> governance (it may be terrible).
> They may do everything terribly, but they still have an EA and they
> still do EA.
> If you don’t use a project management methodology (e.g. Prince2, MSP)
> does this mean you don’t do project management? No.
> Frameworks help people to do what they are doing in a more efficient,
> better, structured way.
> EA is no different to Prince, MSP, Six Sigma, LEAN, ITIL, COBIT, etc
> etc etc.
> They are all frameworks/.methodologies/methods for improving thngs.
> They just scratch different itches.
> @Joseph: “But, all your efforts would be towards populating the as-is
> with lower- level details more useful for support/operations rather
> than architecture. Not a wasted effort, IMHO. But, I wouldn't want to
> be spending all my architecture efforts in documenting the complete
> as- is. I would never hope to complete this task... :-)”
> Correct - which is why you don’t approach modelling that way.
> A lot of people do and they mostly fail because it’s the wrong
> process.
> Not sure what “started EA before they started with the tools.” means -
> but as I understood it (after sitting through the presentation) they
> only way they started was to buy a tool, figure out a good question
> they wanted to answer that would give a big return (application
> portfolio rationalisation), populated the tool with the data required,
> made some changes, save d a lot of money, modelled some more, etc,
> etc.
Hmmm... that sounds like a fool with a tool approach. We could apply this same principle to any (not necessarily EA) tool and start a business model around that tool, viz. "buy a tool, figure out a good question they wanted to answer that would give a big return, populated the tool with the data required, made some changes, save d a lot of money, modelled some more, etc, etc." Et Voila, I've got a new business case. Let us buy a hammer (or whatever the latest jazzy thing the advertising industry is throwing at us), figure out a good question... that would give a big return,... etc etc.
But further down your post, you answer exactly what I meant. You probably figured that yourself
> Which is why I asked Colin Birchenall after the presentation.
And the answer contains the EA approach and the tool was part of their solution. Purrfect!
> to start modelling stuff, so we can
> understand stuff, so we can kill stuff where we don’t need it, and
> strengthen stuff where we do”
And what a brilliant way to gain buy-in from the business owners:
> the only way we can work with you and
> generate a return for all is to
I like this approach. Either we agree on a clear approach and work together and generate a return for all. Or we can't generate a return and won't work with you! Any waffling rhetoric about fluffy stuff just muddies the water for the sponsors and disengage them.
Kind regards,
Joseph
On May 24, 4:01 pm, "Kevin (PragmaticEA.com) Smith"
> @Joseph: “However, I would venture to say from the example he gives
> that they started EA before they started with the tools. All it means
> is that they started using the tool, before they had a complete EA
> vision populated.”
> Not sure what “started EA before they started with the tools.” means -
> but as I understood it (after sitting through the presentation) they
> only way they started was to buy a tool, figure out a good question
> they wanted to answer that would give a big return (application
> portfolio rationalisation), populated the tool with the data required,
> made some changes, save d a lot of money, modelled some more, etc,
> etc.
> They started at the application /infrastructure level then moved up
> into solution architecture, then project portfolio then strategy.
> The point being they did stuff that saved money.
> The question, of course is…
> “OK - but you needed a mandate/money etc to buy the tool, have some
> training, and the people to do some modelling etc right? So how did
> you get the mandate/money ?”
> Which is why I asked Colin Birchenall after the presentation.
> Hi answer was - “Yes, exactly right - the catalyst was the formation
> of the LLP between Serco and Glasgow City Council. Serco had basically
> said, OK - you want us to be in partnership with you in terms of
> provision of IT? = no problem - the only way we can work with you and
> generate a return for all is to start modelling stuff, so we can
> understand stuff, so we can kill stuff where we don’t need it, and
> strengthen stuff where we do”
> Colin also agreed that what they had done was not rocket science and
> simply common sense and that many many organisations have many people
> who already know what should be done and how it should be done but
> they don’t get the remit/budget/mandate to do anything.
> Which is why I have started thinking that the best way to get
> organisations to adopt EA is to marry the education and awareness
> approach with a catalyst approach. There are many…
> - Mergers & Acquisitions
> - Business Unit Consolidation
> - Introduction of New Products, Services or Lines of Business
> - Outsourcing a Business Function
> - Divesting a line of Business
> - Operational Cost Reduction
> - Business Transformation
> - Building Relocation
> - Strategic Planning
> - Increase Business Agility, Efficiency and Effectiveness
> - Streamlining Business Processes
> - Consolidation of Suppliers, Technologies or Applications
> - Business Process Management
> - Business Process Re-engineering
> - Off shoring
> - Market/Shareholder Pressure
> @Joseph: “, EA …..is an iterative process. You could start anywhere in
> this circle”
> Sort of. some things you can some things you cant; For example, you
> can just start modelling stuff before buying a proper tool, however
> you can’t start doing governance using principles (operate) until you
> a) have agreed what they are and b) made the changes in the
> organisation required to operate them (Implement)
> @Joseph: “Just because you have an EA team using an EA tool, doesn't
> mean you are actually performing EA.”
> I would say yes and no.
> My higher level view is that EA is generally about strategic planning,
> modeeling and governance.
> Based on this, I would say that 99.9999% of organisations are already
> “doing” EA. They already do strategic planning (it may be terrible),
> they already do modelling (it may be terrible) they already do
> governance (it may be terrible).
> They may do everything terribly, but they still have an EA and they
> still do EA.
> If you don’t use a project management methodology (e.g. Prince2, MSP)
> does this mean you don’t do project management? No.
> Frameworks help people to do what they are doing in a more efficient,
> better, structured way.
> EA is no different to Prince, MSP, Six Sigma, LEAN, ITIL, COBIT, etc
> etc etc.
> They are all frameworks/.methodologies/methods for improving thngs.
> They just scratch different itches.
> @Joseph: “But, all your efforts would be towards populating the as-is
> with lower- level details more useful for support/operations rather
> than architecture. Not a wasted effort, IMHO. But, I wouldn't want to
> be spending all my architecture efforts in documenting the complete
> as- is. I would never hope to complete this task... :-)”
> Correct - which is why you don’t approach modelling that way.
> A lot of people do and they mostly fail because it’s the wrong
> process.
Chancellor takes the axe to IT spending
tags
gov
And why not? The public sector is possibly best placed to gain benefits from Enterprise Architecture practised at the highest-levels. Just look at the plethora of services and assets scattered around the public estates funded by the same taxpayer and you can just about imagine the wasted (not just IT) expenditure behind the scenes.
Scope of Enterprise Architects in Cloud Computing World!
That entirely depends on where you, as an architect, are sitting - inside the cloud within the cloud operator or outside the cloud within the cloud user. Either way, the architecture principles remain the same, but the operations and business model are radically different.
Best regards,
Joseph
On May 24, 7:00 am, N Gowthaman wrote:
> Group,
> I am curious to understand the scope an Architect will be having in his
> profession with the advent of cloud computing space. Your thoughts pl
> N. Gowthaman
Best regards,
Joseph
On May 24, 7:00 am, N Gowthaman
> Group,
> I am curious to understand the scope an Architect will be having in his
> profession with the advent of cloud computing space. Your thoughts pl
> N. Gowthaman
Tool first or Purpose first for EA
Good post by Kevin! However, I would venture to say from the example he gives that they started EA before they started with the tools. All it means is that they started using the tool, before they had a complete EA vision populated.
Also, EA (whatever framework you use) is an iterative process. You could start anywhere in this circle. As long as you complete a full iteration and preferably a second one, it shouldn't matter where you started out. But you would definitely have had an EA to start with. Most (or rather all) organisations have an EA. Whether they admit it or not, whether it is visible as an EA team or not, is a different matter.
What we are probably referring to, when we mention EA, is perhaps a formal EA team with a defined methodology using an accepted framework and documented fully. IMHO, that is an ideal state, and practically unfeasible and perhaps unrealistic. EA usually never completes. As EA is an iterative process, by the time you reach your goal, it probably might be time to start over again with the next iteration...!!!
Just because you have an EA team using an EA tool, doesn't mean you are actually performing EA.
I would think that having a tool is helpful for completing your EA. But, all your efforts would be towards populating the as-is with lower-level details more useful for support/operations rather than architecture. Not a wasted effort, IMHO. But, I wouldn't want to be spending all my architecture efforts in documenting the complete as-is. I would never hope to complete this task... :-)
Best regards,
Joseph
On May 19, 9:23 am, "Kevin (PragmaticEA.com) Smith" wrote:
> first and Tool second" or "Tool First and Architecture Strategy
> second".”
> Using and or starting with a tool is an eminently valid approach to
> start the adoption of EA and EA practises.
> It has been used successfully by many many organisations, for example,
> by Colin Birchenalls presentation at this weeks Gartner EA conference
> in London, where starting with a tool was the absolute best approach
> for Serco and Glasgow City Councils LLP and for the many successes
> they have achieved in growing up to the full EA level by delivering
> massive and real value to the business by modelling using a tool.
> There are many people who have completely failed by starting with a
> tool.
> The reason for this failure is NOT because starting with a tool is
> wrong or bad.
> The reason is (as with many many things that EA seeks to address) is
> process.
> Many people incorrectly start to use the tool (one example of bad
> process but there are many other ways of failing) by modelling the
> heck out of everything and after 6 months (or years for some failed
> attempts) the CEO asks what have we gained and the answer is nothing.
> Don't blame the tool is you use the tool incorrectly. Don't blame the
> screwdriver if you try to hammer nails in with it.
> The successful process for using a tool is actually very simple...
> Stage 1 – Determine the Question
> Identity a high level business question that the management wants an
> answer to, that they either: -
> a) Currently cannot answer, or
> b) Can get an answer but the quality and confidence in that answer is
> too low to be useful.
> Stage 2 – Determine Required Data
> Having understood what the question is, this stage identifies what
> information will be required to answer it. It should be noted that the
> temptation to try to answer the question should be resisted.
> Stage 3 – Populate the Model
> The third stage of the iteration is to find and populate the model
> with the information identified. This sub-process is described in
> detail in the next section
> Stage 4 – Integrate the Model
> This phase ensures that the work that has been done and the
> information loaded into the model is sustainable. For each of the
> Datasources there are two alternatives (which were identified in the
> Analysis Phase).
> a) The Datasource is removed – The processes and people using the
> original Datasource will stop using it and will use the information in
> the model.
> b) The Datasource is preserved – The necessary interfaces are built to
> enable the synchronisation and management of the data going forward.
> Stage 5 – Answer the question
> Having populated the model, it is now possible to use the mode in
> concert with the tools and analyses provided by the modelling tool the
> answer the business question. After this, another iteration is
> possible.
> fyi, I have just started a related discussion the EA Network Linked In
> discussion group (http://www.linkedin.com/groups?home=&gid=36781)
> entitled …
> GARTNER: "A FOOL WITH A TOOL IS STILL A FOOL"
> I was dismayed to hear this same staid, tired and, IMHO, damaging
> catchphrase at this weeks Gartner EA summit in London (May 2010).
>http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=3678...
Also, EA (whatever framework you use) is an iterative process. You could start anywhere in this circle. As long as you complete a full iteration and preferably a second one, it shouldn't matter where you started out. But you would definitely have had an EA to start with. Most (or rather all) organisations have an EA. Whether they admit it or not, whether it is visible as an EA team or not, is a different matter.
What we are probably referring to, when we mention EA, is perhaps a formal EA team with a defined methodology using an accepted framework and documented fully. IMHO, that is an ideal state, and practically unfeasible and perhaps unrealistic. EA usually never completes. As EA is an iterative process, by the time you reach your goal, it probably might be time to start over again with the next iteration...!!!
Just because you have an EA team using an EA tool, doesn't mean you are actually performing EA.
I would think that having a tool is helpful for completing your EA. But, all your efforts would be towards populating the as-is with lower-level details more useful for support/operations rather than architecture. Not a wasted effort, IMHO. But, I wouldn't want to be spending all my architecture efforts in documenting the complete as-is. I would never hope to complete this task... :-)
Best regards,
Joseph
On May 19, 9:23 am, "Kevin (PragmaticEA.com) Smith"
> first and Tool second" or "Tool First and Architecture Strategy
> second".”
> Using and or starting with a tool is an eminently valid approach to
> start the adoption of EA and EA practises.
> It has been used successfully by many many organisations, for example,
> by Colin Birchenalls presentation at this weeks Gartner EA conference
> in London, where starting with a tool was the absolute best approach
> for Serco and Glasgow City Councils LLP and for the many successes
> they have achieved in growing up to the full EA level by delivering
> massive and real value to the business by modelling using a tool.
> There are many people who have completely failed by starting with a
> tool.
> The reason for this failure is NOT because starting with a tool is
> wrong or bad.
> The reason is (as with many many things that EA seeks to address) is
> process.
> Many people incorrectly start to use the tool (one example of bad
> process but there are many other ways of failing) by modelling the
> heck out of everything and after 6 months (or years for some failed
> attempts) the CEO asks what have we gained and the answer is nothing.
> Don't blame the tool is you use the tool incorrectly. Don't blame the
> screwdriver if you try to hammer nails in with it.
> The successful process for using a tool is actually very simple...
> Stage 1 – Determine the Question
> Identity a high level business question that the management wants an
> answer to, that they either: -
> a) Currently cannot answer, or
> b) Can get an answer but the quality and confidence in that answer is
> too low to be useful.
> Stage 2 – Determine Required Data
> Having understood what the question is, this stage identifies what
> information will be required to answer it. It should be noted that the
> temptation to try to answer the question should be resisted.
> Stage 3 – Populate the Model
> The third stage of the iteration is to find and populate the model
> with the information identified. This sub-process is described in
> detail in the next section
> Stage 4 – Integrate the Model
> This phase ensures that the work that has been done and the
> information loaded into the model is sustainable. For each of the
> Datasources there are two alternatives (which were identified in the
> Analysis Phase).
> a) The Datasource is removed – The processes and people using the
> original Datasource will stop using it and will use the information in
> the model.
> b) The Datasource is preserved – The necessary interfaces are built to
> enable the synchronisation and management of the data going forward.
> Stage 5 – Answer the question
> Having populated the model, it is now possible to use the mode in
> concert with the tools and analyses provided by the modelling tool the
> answer the business question. After this, another iteration is
> possible.
> fyi, I have just started a related discussion the EA Network Linked In
> discussion group (http://www.linkedin.com/groups?home=&gid=36781)
> entitled …
> GARTNER: "A FOOL WITH A TOOL IS STILL A FOOL"
> I was dismayed to hear this same staid, tired and, IMHO, damaging
> catchphrase at this weeks Gartner EA summit in London (May 2010).
>http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=3678...
Doing Business without EA is like building a chain of “open” links
tags
philosophy,
tea.net
Lewis Caroll in Alice's Adventures in Wonderland:
Alice came to a fork in the road. "Which road do I take?" she asked.
"Where do you want to go?" responded the Cheshire cat.
"I don't know," Alice answered.
"Then," said the cat, "it doesn't matter."
Framework method
tags
business.architecture,
framework,
tea.net,
togaf
> That is made clear in the Structure of the TOGAF
> Document Figure in which business vision and drivers and business
> capabilities are clearly outside of the architecture.
Not exactly outside, George! Rather the other way around... everything else is subsumed within (and follows from) Business Architecture, unless you are building an organisation bottom-up (which is not untrue of many I have seen). See this from TOGAF9:
Best regards,
Joseph
On Apr 27, 2:41 pm, "Pitagorsky George"
wrote:
> I agree that TOGAF centers on the IT, as do mot of the EA initiatives I
> have encountered. That is made clear in the Structure of the TOGAF
> Document Figure in which business vision and drivers and business
> capabilities are clearly outside of the architecture. The figure
> includes a reference to "non-architectural aspects of business
> operations." Even the business architecture piece refers to the
> business architecture as a means to "support an agreed Architecture
> Vision", implying that the business architecture is something outside of
> the architecture itself.
> The integration of all aspects of the enterprise into an architectural
> vision is a logical extension of an architecture approach. It is a
> challenge to make the transition from IT architecture supported by
> business architecture for use in governance and expense control to a
> true enterprise architecture that sets a stage for ongoing process
> optimization. To make that transition, there is need for cultural
> change.
> George Pitagorsky
> Consultant at NYC Dept of Education
> 718 707 4536
> -----Original Message-----
> From: Kevin (PragmaticEA.com) Smith
> Sent: Monday, April 26, 2010 3:51 PM
> Subject: Re: Framework method
> @Andrew Galletly:" Togaf does state that the inputs to the
> Architecture Vision "such as the enterprise mission, vision, strategy,
> and goals - have been documented as part of some wider business
> strategy or enterprise planning activity that has its own lifecycle
> within the enterprise", however, they are still an input and as such
> form the scope of any subsequent architecture work. Is the omission
> of this
> Business Context-type work your rationale for stating Togaf is not an
> EA Framework?"
> Yes. But that's not the only difference/reason why I say TOGAF is not
> an EA framework.
> As soon as you get down to project level work, it's not EA. EA does
> exist at that level but only regarding governance and the
> identification and management of Enterprise Debt.
> EA is much much more about strategic planning and about connecting the
> entire breadth of the enterprise but not the depth. EA (IMHO) is a
> cultural approach.
> You can have a look at how I contrast TOGAF with other EA frameworks
> at
> http://www.pragmaticea.com/display-doc.asp?DocName=peaf-overview1-framework-comparison
> Page 10 gives you a 3 dimensional comparison using 6 axes.
> Document Figure in which business vision and drivers and business
> capabilities are clearly outside of the architecture.
Not exactly outside, George! Rather the other way around... everything else is subsumed within (and follows from) Business Architecture, unless you are building an organisation bottom-up (which is not untrue of many I have seen). See this from TOGAF9:
Best regards,
Joseph
On Apr 27, 2:41 pm, "Pitagorsky George"
wrote:
> I agree that TOGAF centers on the IT, as do mot of the EA initiatives I
> have encountered. That is made clear in the Structure of the TOGAF
> Document Figure in which business vision and drivers and business
> capabilities are clearly outside of the architecture. The figure
> includes a reference to "non-architectural aspects of business
> operations." Even the business architecture piece refers to the
> business architecture as a means to "support an agreed Architecture
> Vision", implying that the business architecture is something outside of
> the architecture itself.
> The integration of all aspects of the enterprise into an architectural
> vision is a logical extension of an architecture approach. It is a
> challenge to make the transition from IT architecture supported by
> business architecture for use in governance and expense control to a
> true enterprise architecture that sets a stage for ongoing process
> optimization. To make that transition, there is need for cultural
> change.
> George Pitagorsky
> Consultant at NYC Dept of Education
> 718 707 4536
> -----Original Message-----
> From: Kevin (PragmaticEA.com) Smith
> Sent: Monday, April 26, 2010 3:51 PM
> Subject: Re: Framework method
> @Andrew Galletly:" Togaf does state that the inputs to the
> Architecture Vision "such as the enterprise mission, vision, strategy,
> and goals - have been documented as part of some wider business
> strategy or enterprise planning activity that has its own lifecycle
> within the enterprise", however, they are still an input and as such
> form the scope of any subsequent architecture work. Is the omission
> of this
> Business Context-type work your rationale for stating Togaf is not an
> EA Framework?"
> Yes. But that's not the only difference/reason why I say TOGAF is not
> an EA framework.
> As soon as you get down to project level work, it's not EA. EA does
> exist at that level but only regarding governance and the
> identification and management of Enterprise Debt.
> EA is much much more about strategic planning and about connecting the
> entire breadth of the enterprise but not the depth. EA (IMHO) is a
> cultural approach.
> You can have a look at how I contrast TOGAF with other EA frameworks
> at
> http://www.pragmaticea.com/display-doc.asp?DocName=peaf-overview1-framework-comparison
> Page 10 gives you a 3 dimensional comparison using 6 axes.
Sustainable Architecture
I particularly liked this from Richard Latham's presentation on Sustainable Enterprise Architecture at The Open Group's 22nd Enterprise Architecture Practitioners Conference:
Framework method
Hmmm... what according to you would be an Enterprise Architecture Framework, Kevin? ;-)
I would agree with Kevin, to a certain extent about TOGAF being dragged down by the weight of its past (and possibly current) IT baggage. Just look at TOGAF 9 Part III Architecture Principles, towards the suggested Business Principles. All the "Business" Principles seem to be about "information management decisions". I would have thought the "information management decisions" would be within the scope of Application Principles or Technology Principles. Architecture Principles are a corner-stone for the whole of the Enterprise decision-making agenda. Not all decision-making is about "information management" alone.
TOGAF9 has made a lot of progress towards focussing on the Enterprise layer, but there is still a lot of ground to be covered, and some to be discarded. You can't be top-heavy and bottom-heavy at the same time. And TOGAF needs to make up its mind where it wants to be - focus on the details at the bottom layers or focus on the decision-making at the upper layers of the enterprise.
Just to clarify, I'm not saying that IT should be completely ignored, as some others seem to be saying. Almost the whole of the enterprise and its operations are IT dependant now. And you simply cannot be making enterprise decisions without understanding the impact on your operations or strategy. IT ignorant decision makers are a key business risk! But, I am very much saying that IT (and anybody else sitting on sidelines) should not be running the enterprise.
Best regards,
Joseph
On Apr 12, 7:14 am, "Kevin (PragmaticEA.com) Smith"
wrote:
> TOGAF is not an Enterprise Architecture Frameowrk.
> TOGAF is an IT Architecture Framework.
I would agree with Kevin, to a certain extent about TOGAF being dragged down by the weight of its past (and possibly current) IT baggage. Just look at TOGAF 9 Part III Architecture Principles, towards the suggested Business Principles. All the "Business" Principles seem to be about "information management decisions". I would have thought the "information management decisions" would be within the scope of Application Principles or Technology Principles. Architecture Principles are a corner-stone for the whole of the Enterprise decision-making agenda. Not all decision-making is about "information management" alone.
TOGAF9 has made a lot of progress towards focussing on the Enterprise layer, but there is still a lot of ground to be covered, and some to be discarded. You can't be top-heavy and bottom-heavy at the same time. And TOGAF needs to make up its mind where it wants to be - focus on the details at the bottom layers or focus on the decision-making at the upper layers of the enterprise.
Just to clarify, I'm not saying that IT should be completely ignored, as some others seem to be saying. Almost the whole of the enterprise and its operations are IT dependant now. And you simply cannot be making enterprise decisions without understanding the impact on your operations or strategy. IT ignorant decision makers are a key business risk! But, I am very much saying that IT (and anybody else sitting on sidelines) should not be running the enterprise.
Best regards,
Joseph
On Apr 12, 7:14 am, "Kevin (PragmaticEA.com) Smith"
> TOGAF is not an Enterprise Architecture Frameowrk.
> TOGAF is an IT Architecture Framework.
System of System
tags
tea.net
I agree! EA is not just focussed across a single LoB, but spans across all the LoBs. All of the LoBs have something in common which brings them coherently together into an enterprise. Otherwise, they would each be enterprises unto themselves, having nothing in common with any other LoBs. And there would be an argument about divesting or spinning off such LoBs. If EA does not raise its focus higher, there is no benefit derived from being part of an enterprise.
I'm not saying the EA should become an ivory tower and not understand the realities at the ground level. This is most often the fall of EA.
Currently, I am engaged in the intergration of an acquisition. What I am trying is to make any requirement into an enterprise requirement, and realise the benefits of the enterprise capabilities and maximise potential. We do not realise any benefits of being part of a larger entity, if everyone has their own way of doing things. Learn from the differences and use that knowledge to leverage your business capabilities. Going pedantic about rationalisation and making every business/technical processes an exact clone across divergent cultures and jurisdictions, might risk killing your business. There is a fine line in between... We need to provide scope for variances on the frontline, as needed.
Best regards,
Joseph
On Apr 14, 4:26 pm, "wpb...@gmail.com" wrote:
> > Another difference is that EA is about the "enterprise" - typically
> > focussed on a single business, whereas a SoS may cross multiple
> > "enterprises" / organisations and address a wider set of interactions
> > (eg, air traffic management including airlines, radar systems, air
> > traffic controllers, flight planning systems)
> That may be true of the approach of many enterprise architects but, is
> not characteristic of the entire discipline nor of all enterprise
> architects. (Up until recently, I was an EA on a systems engineering
> team at the FAA and I was always mindful of interactions with external
> parties, particularly those represented in the JPDO.) The "enterprise"
> is not a physical/legal entity, rather, it is the entire scope of the
> domain and participants, at hand. And that is pretty much all the
> consideration the definition needs for practical purposes. In this
> case, NextGen was the "enterprise", not just the FAA and not just the
> DoD, etc. As one of the systems engineers mused, EA really isn't
> "enterprise" architecture as much as it is "ecosystem" architecture.
I'm not saying the EA should become an ivory tower and not understand the realities at the ground level. This is most often the fall of EA.
Currently, I am engaged in the intergration of an acquisition. What I am trying is to make any requirement into an enterprise requirement, and realise the benefits of the enterprise capabilities and maximise potential. We do not realise any benefits of being part of a larger entity, if everyone has their own way of doing things. Learn from the differences and use that knowledge to leverage your business capabilities. Going pedantic about rationalisation and making every business/technical processes an exact clone across divergent cultures and jurisdictions, might risk killing your business. There is a fine line in between... We need to provide scope for variances on the frontline, as needed.
Best regards,
Joseph
On Apr 14, 4:26 pm, "wpb...@gmail.com"
> > Another difference is that EA is about the "enterprise" - typically
> > focussed on a single business, whereas a SoS may cross multiple
> > "enterprises" / organisations and address a wider set of interactions
> > (eg, air traffic management including airlines, radar systems, air
> > traffic controllers, flight planning systems)
> That may be true of the approach of many enterprise architects but, is
> not characteristic of the entire discipline nor of all enterprise
> architects. (Up until recently, I was an EA on a systems engineering
> team at the FAA and I was always mindful of interactions with external
> parties, particularly those represented in the JPDO.) The "enterprise"
> is not a physical/legal entity, rather, it is the entire scope of the
> domain and participants, at hand. And that is pretty much all the
> consideration the definition needs for practical purposes. In this
> case, NextGen was the "enterprise", not just the FAA and not just the
> DoD, etc. As one of the systems engineers mused, EA really isn't
> "enterprise" architecture as much as it is "ecosystem" architecture.
What is a good tool to use for a small organizations EA?
George,
Wouldn't you be part of the government procurement process? And if so, I would certainly take advantage of it or have a look at their portfolio. I wouldn't recommend one of the big Architecture-Tool vendors for your school per se. Alternatively, there are some open source tools available, and I have heard some good reports. As I myself haven't used any of those architecture tools, I will let others recommend from their experience.
You could start with Open Office or the many equivalent Open Source or Cloud offerings. Dia could be used for modelling. I actually like Dia. It has templates or shapes for mapping processes (EPC), systems (LST), infrastructure (CDP, racks), and even for energy. I would suggest that, if we use any of these products, we look to contribute back in some way.
I would look to use the web (inter or intra) for publishing, rather than pushing out stacks of static documents.
Kind regards,
Joseph
On Mar 30, 4:01 pm, GeorgeP wrote:
> I am leading a program to establish an EA and governance process for a
> moderate sized local govt agency. We are beginning to look at tools
> and have limited budget. Any ideas as to the best tools for
> inventorying and linking applications and infrastructure elements and
> business processes?
Wouldn't you be part of the government procurement process? And if so, I would certainly take advantage of it or have a look at their portfolio. I wouldn't recommend one of the big Architecture-Tool vendors for your school per se. Alternatively, there are some open source tools available, and I have heard some good reports. As I myself haven't used any of those architecture tools, I will let others recommend from their experience.
You could start with Open Office or the many equivalent Open Source or Cloud offerings. Dia could be used for modelling. I actually like Dia. It has templates or shapes for mapping processes (EPC), systems (LST), infrastructure (CDP, racks), and even for energy. I would suggest that, if we use any of these products, we look to contribute back in some way.
I would look to use the web (inter or intra) for publishing, rather than pushing out stacks of static documents.
Kind regards,
Joseph
On Mar 30, 4:01 pm, GeorgeP
> I am leading a program to establish an EA and governance process for a
> moderate sized local govt agency. We are beginning to look at tools
> and have limited budget. Any ideas as to the best tools for
> inventorying and linking applications and infrastructure elements and
> business processes?
Metaphysical Architecture
tags
knowledge,
philosophy,
tea.net
For once, I am truly lost for words, dear Sir!
:-j
PS: I hope you are suggesting that I am a nice person.
PPS: I've changed the subject to create a new thread, so as not to distract from the OP and his thread.
On Mar 30, 7:43 pm, Adrian Miley wrote:
> Joseph,
> I've a feeling that you do exist but it might only be in the
> metaphysical sense as I've not witnessed a physical manifestation
> yet.
> However, if you don't have phyiscal manifestation then hopefully you
> can take comfort in the fact that your existential existence is on a
> par with most of the interesting things in the multi-verse. Even
> concepts can be nice people to.
> I on the other hand definitely do exist - I've created an entire sub-
> reality for myself just to support my manifestation. Unfortunately the
> knowledge transfer mechanism necessary to communicate the proof of
> that doesn't yet exist outside my sub-reality so hopefuilly you'll
> take my word for it :-)
> Adrian
> On 30 Mar, 09:26, Joseph George southern.co.uk> wrote:
> > Wow... this metaphysical stuff is really deep and interesting!! IMHO,
> > definitely deserves its own thread...
> > :-j
> > PS: Do I exist? What does your sensory perception indicate? Do you??
> > On Mar 30, 8:47 am, Adrian Miley wrote:
> > > Geoff,
> > > “Knowledge cannot be shared as it is highly contextual based.”
> > > All Knowledge is (a type of) Information and all Information is (a
> > > type of) Data with the additional characteristics essentially being
> > > Context and Purpose. So given that Data can be transferred then both
> > > Knowledge and Information can also be transferred providing that the
> > > Context and Purpose can be suitable captured and transferred.
> > > So you correctly point out (and contradicting your own original
> > > assertion) the issue is not that Knowledge can’t be transferred but
> > > that it can only be transferred as accurately as the chosen knowledge
> > > transference mechanism allows. Unfortunately for this we appear to be
> > > using a token-based language which are notoriously imprecise because
> > > the meaning of each token is not unambiguous and has different meaning
> > > to different people (as Bertrand Russell said “It’s possible to be
> > > both clear and precise but not at the same time!”)
> > > In mathematics, on the other hand, accurate and complete knowledge
> > > transference takes place regularly but that’s mainly because the
> > > language of mathematics is well-defined and unambiguous so
> > > consequently not open to local interpretation by the recipient of the
> > > knowledge.
> > > You yourself allude to a potential solution to the problem and once we
> > > develop Telepathy for the masses then knowledge transfer will be both
> > > complete and accurate. (Though I do hope that happens after I’m dead
> > > because if anyone poked around the chaos-realm I call “my mind” they’d
> > > probably question my sanity.)
> > > Hence, to conclude, it’s not impossible to transfer knowledge just
> > > very difficult and if you’d made that assertion then I’d agree with
> > > you but to say it CANNOT be done is inaccurate because a potential
> > > solution is conceivable.
> > > That last point also challenges your assertion that systems do not
> > > exist. To quote Paul Adams (Cambridge University, 1920’s) “Physical
> > > manifestation is not a requirement for existence” that is, the act of
> > > thinking about something brings it into existence therefore something
> > > called a “system” exists simply because. Philosophy, both physical or
> > > metaphysical, is full of existential concepts that have unproven
> > > physical manifestation but proven behaviour.
> > > Both systems and the ability to transfer knowledge are conceivable so
> > > therefore are both possible.
> > > Just my opinion…
> > > On 29 Mar, 16:24, "Geoff" wrote:
> > > > HI Kevin
> > > > See the work of polyani. Knowledge cannot be shared as it is highly
> > > > contextual based. In KM one also has to differentiate between know what and
> > > > know how's
> > > > At the same recognized that people know more than they can tell. I can give
> > > > you some information, i.e point you in the direction of Polyani and also
> > > > point you in direction of mode 1 and mode 2 knowledge but I cannot transfer
> > > > my experiential learning into some ones head. In other knowledge cannot be
> > > > transferred, information yes. I get information from books but not
> > > > knowledge.
> > > > I can also list the basic principles behind systems theory. As for doing the
> > > > knowledge a la a London cabbie tyhgis is highly contextural and read ing his
> > > > book does not tell me what he knows. If knowledge can be held in an IT
> > > > system then why have only 2 may be 3 companies built a KM system?
> > > > Thoughts
> > > > Geoff
> > > > PS
> > > > -----Original Message-----
> > > > From: Kevin (PragmaticEA.com) Smith
> > > > Sent: 28 March 2010 21:27
> > > > Subject: Re: Using EA to dis-integrate an enterprise architecture?
> > > > @Doug: "I will think about how to position a separate thread around
> > > > cybernetics and
> > > > systems theory."
> > > > Cool. I'm always looking to expand my horizons.
> > > > And a discussion about it in this group would be a great way for yours
> > > > (and others) knowledge to be shared with those that currently do not
> > > > have the knowledge, such that in one sense the knowledge will be
> > > > transferred from one place (aka you and others) to another place (aka
> > > > me and others) in a way that could probably be defined as knowledge
> > > > transfer ;-)
> > > > @Doug: "On the point you raise about talking to clients of EA about
> > > > such things, I generally don't."
> > > > Yep - I was kind of getting that feeling. It's more an internal anchor
> > > > and sextant I guess.
> > > > @Geoff: "Please explain how knowledge can be shared? Data and
> > > > Information yes but not knowledge, absolutely NO. See the work of
> > > > Polyani. Knowledge is not found in Books on or the net and cannot be
> > > > transferred."
> > > > Please see my response above. That should give you a small example of
> > > > how knowledge can be shared. Of course, I am but a simple man and am
> > > > using the definition of the word "knowledge" as described in the
> > > > dictionary (Websters in this instance) and how it has been used
> > > > throughout my life which may not be what you understand to be the
> > > > definition of "knowledge", and if so please let me know your
> > > > definition so we can have a meaningful dialogue otherwise we are
> > > > talking apples and pears.
> > > > By the way, I am sure you are aware of the act of "Doing the
> > > > Knowledge".I would be interested in observing a conversation between
> > > > you and a London Cabby. (The best in the world).
> > > > Geoff, I can see by your comments and your previous groups that you
> > > > regard yourself as a bit of an anarchist. Interestingly so do I. I
> > > > have suffered the slings and arrows of outrageous fortune, and have
> > > > taken arms against a sea of troubles and all my sins will be
> > > > remembered.
> > > > Brain the size of a planet and they ask me to pick up a piece of
> > > > paper..
:-j
PS: I hope you are suggesting that I am a nice person.
PPS: I've changed the subject to create a new thread, so as not to distract from the OP and his thread.
On Mar 30, 7:43 pm, Adrian Miley
> Joseph,
> I've a feeling that you do exist but it might only be in the
> metaphysical sense as I've not witnessed a physical manifestation
> yet.
> However, if you don't have phyiscal manifestation then hopefully you
> can take comfort in the fact that your existential existence is on a
> par with most of the interesting things in the multi-verse. Even
> concepts can be nice people to.
> I on the other hand definitely do exist - I've created an entire sub-
> reality for myself just to support my manifestation. Unfortunately the
> knowledge transfer mechanism necessary to communicate the proof of
> that doesn't yet exist outside my sub-reality so hopefuilly you'll
> take my word for it :-)
> Adrian
> On 30 Mar, 09:26, Joseph George
> > Wow... this metaphysical stuff is really deep and interesting!! IMHO,
> > definitely deserves its own thread...
> > :-j
> > PS: Do I exist? What does your sensory perception indicate? Do you??
> > On Mar 30, 8:47 am, Adrian Miley
> > > Geoff,
> > > “Knowledge cannot be shared as it is highly contextual based.”
> > > All Knowledge is (a type of) Information and all Information is (a
> > > type of) Data with the additional characteristics essentially being
> > > Context and Purpose. So given that Data can be transferred then both
> > > Knowledge and Information can also be transferred providing that the
> > > Context and Purpose can be suitable captured and transferred.
> > > So you correctly point out (and contradicting your own original
> > > assertion) the issue is not that Knowledge can’t be transferred but
> > > that it can only be transferred as accurately as the chosen knowledge
> > > transference mechanism allows. Unfortunately for this we appear to be
> > > using a token-based language which are notoriously imprecise because
> > > the meaning of each token is not unambiguous and has different meaning
> > > to different people (as Bertrand Russell said “It’s possible to be
> > > both clear and precise but not at the same time!”)
> > > In mathematics, on the other hand, accurate and complete knowledge
> > > transference takes place regularly but that’s mainly because the
> > > language of mathematics is well-defined and unambiguous so
> > > consequently not open to local interpretation by the recipient of the
> > > knowledge.
> > > You yourself allude to a potential solution to the problem and once we
> > > develop Telepathy for the masses then knowledge transfer will be both
> > > complete and accurate. (Though I do hope that happens after I’m dead
> > > because if anyone poked around the chaos-realm I call “my mind” they’d
> > > probably question my sanity.)
> > > Hence, to conclude, it’s not impossible to transfer knowledge just
> > > very difficult and if you’d made that assertion then I’d agree with
> > > you but to say it CANNOT be done is inaccurate because a potential
> > > solution is conceivable.
> > > That last point also challenges your assertion that systems do not
> > > exist. To quote Paul Adams (Cambridge University, 1920’s) “Physical
> > > manifestation is not a requirement for existence” that is, the act of
> > > thinking about something brings it into existence therefore something
> > > called a “system” exists simply because. Philosophy, both physical or
> > > metaphysical, is full of existential concepts that have unproven
> > > physical manifestation but proven behaviour.
> > > Both systems and the ability to transfer knowledge are conceivable so
> > > therefore are both possible.
> > > Just my opinion…
> > > On 29 Mar, 16:24, "Geoff"
> > > > HI Kevin
> > > > See the work of polyani. Knowledge cannot be shared as it is highly
> > > > contextual based. In KM one also has to differentiate between know what and
> > > > know how's
> > > > At the same recognized that people know more than they can tell. I can give
> > > > you some information, i.e point you in the direction of Polyani and also
> > > > point you in direction of mode 1 and mode 2 knowledge but I cannot transfer
> > > > my experiential learning into some ones head. In other knowledge cannot be
> > > > transferred, information yes. I get information from books but not
> > > > knowledge.
> > > > I can also list the basic principles behind systems theory. As for doing the
> > > > knowledge a la a London cabbie tyhgis is highly contextural and read ing his
> > > > book does not tell me what he knows. If knowledge can be held in an IT
> > > > system then why have only 2 may be 3 companies built a KM system?
> > > > Thoughts
> > > > Geoff
> > > > PS
> > > > -----Original Message-----
> > > > From: Kevin (PragmaticEA.com) Smith
> > > > Sent: 28 March 2010 21:27
> > > > Subject: Re: Using EA to dis-integrate an enterprise architecture?
> > > > @Doug: "I will think about how to position a separate thread around
> > > > cybernetics and
> > > > systems theory."
> > > > Cool. I'm always looking to expand my horizons.
> > > > And a discussion about it in this group would be a great way for yours
> > > > (and others) knowledge to be shared with those that currently do not
> > > > have the knowledge, such that in one sense the knowledge will be
> > > > transferred from one place (aka you and others) to another place (aka
> > > > me and others) in a way that could probably be defined as knowledge
> > > > transfer ;-)
> > > > @Doug: "On the point you raise about talking to clients of EA about
> > > > such things, I generally don't."
> > > > Yep - I was kind of getting that feeling. It's more an internal anchor
> > > > and sextant I guess.
> > > > @Geoff: "Please explain how knowledge can be shared? Data and
> > > > Information yes but not knowledge, absolutely NO. See the work of
> > > > Polyani. Knowledge is not found in Books on or the net and cannot be
> > > > transferred."
> > > > Please see my response above. That should give you a small example of
> > > > how knowledge can be shared. Of course, I am but a simple man and am
> > > > using the definition of the word "knowledge" as described in the
> > > > dictionary (Websters in this instance) and how it has been used
> > > > throughout my life which may not be what you understand to be the
> > > > definition of "knowledge", and if so please let me know your
> > > > definition so we can have a meaningful dialogue otherwise we are
> > > > talking apples and pears.
> > > > By the way, I am sure you are aware of the act of "Doing the
> > > > Knowledge".I would be interested in observing a conversation between
> > > > you and a London Cabby. (The best in the world).
> > > > Geoff, I can see by your comments and your previous groups that you
> > > > regard yourself as a bit of an anarchist. Interestingly so do I. I
> > > > have suffered the slings and arrows of outrageous fortune, and have
> > > > taken arms against a sea of troubles and all my sins will be
> > > > remembered.
> > > > Brain the size of a planet and they ask me to pick up a piece of
> > > > paper..
How would you justify accessibility as an EA/compliance requirement.
tags
accessibility,
disability,
legislation,
tea.net
Pawel,
As Stuart mentioned previously, the UK has very well-defined accessibility legislations. This is what the UK government legislates for disabled people:
http://direct.gov.uk/en/DisabledPeople/
The DDA (Disability Discrimination Act 2005) can be found here:
http://opsi.gov.uk/Acts/acts2005/ukpga_20050013_en_1
The DRC (Disability Rights Commission Act 1999) can be found here:
http://opsi.gov.uk/acts/acts1999/ukpga_19990017_en_1
The DWP (Department for Work & Pensions) recommends the WAI (Web Accessibility Initiative).
http://dwp.gov.uk/employer/disability-discrimination-act/what-can-i-do/
http://w3.org/WAI/
Perhaps more pertinent to you might be the RNIB (Royal National Institute for the Blind) and their guidance:
http://www.rnib.org.uk/professionals/webaccessibility/usefullinks/Pages/useful_links.aspx
> I know that accessibility is not the center point of
> requirements, but it can be benefitial. The problem is that you need to
> justify it and it does require quite an effort for people are not familiar
> with the issue. I am not the fan of flaming them how bad they are and how
> they send all the people with some kind of special needs to the recycle bin.
> I wanted to hear some voices on how to get accessibility on board without
> making extreme effort.
I don't think you should have this problem, unless you are asking for a separate budget for developing accessibility solutions which you might be wanting to (sell and/or) implement independantly.
The implications are legal compliance and regulatory requirement across horizontals, which is not an option or a subject for debate. I don't think any of the directors would veto these.
As you can see, there is a lot of help, guidance and support for what you are looking for in the UK. This can carry the teeth you are looking for too. I'm afraid I can't comment on other countries, and there are others far more qualified in their own respective countries and domains.
Best regards,
Joseph
On Mar 11, 7:56 pm, "Pawel Urbanski" wrote:
> Hi Stuart
> Thanks for your reply. I know that accessibility is not the center point of
> requirements, but it can be benefitial. The problem is that you need to
> justify it and it does require quite an effort for people are not familiar
> with the issue. I am not the fan of flaming them how bad they are and how
> they send all the people with some kind of special needs to the recycle bin.
> I wanted to hear some voices on how to get accessibility on board without
> making extreme effort.
> I stated it from the regulatory/compliance point of view because it is easy
> to give Section 508 or W3C's WCAG recommendation as an example. The American
> government frequently puts Section 508 as a compliance requirement - at
> least it is how it looks like to my knowledge collected from some friends
> working in the software industry in the USA.
> I really enjoyed your comments - especially showing some different angle in
> the placement of accessibility as an UI issue or business issue.
> Thanks a lot,
> Pawel
> ----- Original Message -----
> From: "Stuart Scott"
> Sent: Thursday, March 11, 2010 2:43 PM
> Subject: Re: How would you justify accessibility as an EA/compliance
> requirement.
> >> Those of you who live and work in the United States or Canada may be more
> >> familiar with the terms than people from Asia or Europe.
> > Note that in the UK the whole issue is made simple due to disability
> > discrimination legislation that mandates reasonable efforts to provide
> > accessibility.
> > However, as suggested by other responders, this is merely a subset of
> > the larger suite of requirements around regulatory and compliance
> > needs, and the non-functional demands on any given system (which may
> > include non-IT components).
> > My approach as an EA is generally to treat non-functional requirements
> > such as accessibility, resilience and DR as givens - such requirements
> > don't act as differentiators on any guidance my team provides because
> > we wouldn't put forward an approach that doesn't meet the basic set of
> > requirements.
> > Recommending a single corporate web presence with CMS based microsites
> > on sub-domains incorporating the various transactional web services
> > provided to our customers is a clear and straightforward
> > recommendation with direct customer, marketing, business, cost and IT
> > implications; that it also has to support accessibility requirements
> > doesn't factor in the recommendation.
> > To me, compliance with regulatory needs is owned by the Compliance
> > team; information security by the Infosec team; infrastructure
> > non-functionals by IT. Where accessibility isn't a regulatory
> > requirement then it's a business requirement, and should be owned by
> > the marketing or customer service teams. At most organisations a
> > straightforward business case will be possible highlighting the cost
> > savings provided by direct customer self-service as opposed to hiring
> > additional contact centre staff.
> > For internal employee accessibility I think that's a legal requirement
> > in the US too? It's a more complicated discussion, but not one we need
> > to have in the UK (due to the regulatory requirements).
> > cheers,
> > ~Stuart
As Stuart mentioned previously, the UK has very well-defined accessibility legislations. This is what the UK government legislates for disabled people:
http://direct.gov.uk/en/DisabledPeople/
The DDA (Disability Discrimination Act 2005) can be found here:
http://opsi.gov.uk/Acts/acts2005/ukpga_20050013_en_1
The DRC (Disability Rights Commission Act 1999) can be found here:
http://opsi.gov.uk/acts/acts1999/ukpga_19990017_en_1
The DWP (Department for Work & Pensions) recommends the WAI (Web Accessibility Initiative).
http://dwp.gov.uk/employer/disability-discrimination-act/what-can-i-do/
http://w3.org/WAI/
Perhaps more pertinent to you might be the RNIB (Royal National Institute for the Blind) and their guidance:
http://www.rnib.org.uk/professionals/webaccessibility/usefullinks/Pages/useful_links.aspx
> I know that accessibility is not the center point of
> requirements, but it can be benefitial. The problem is that you need to
> justify it and it does require quite an effort for people are not familiar
> with the issue. I am not the fan of flaming them how bad they are and how
> they send all the people with some kind of special needs to the recycle bin.
> I wanted to hear some voices on how to get accessibility on board without
> making extreme effort.
I don't think you should have this problem, unless you are asking for a separate budget for developing accessibility solutions which you might be wanting to (sell and/or) implement independantly.
The implications are legal compliance and regulatory requirement across horizontals, which is not an option or a subject for debate. I don't think any of the directors would veto these.
As you can see, there is a lot of help, guidance and support for what you are looking for in the UK. This can carry the teeth you are looking for too. I'm afraid I can't comment on other countries, and there are others far more qualified in their own respective countries and domains.
Best regards,
Joseph
On Mar 11, 7:56 pm, "Pawel Urbanski"
> Hi Stuart
> Thanks for your reply. I know that accessibility is not the center point of
> requirements, but it can be benefitial. The problem is that you need to
> justify it and it does require quite an effort for people are not familiar
> with the issue. I am not the fan of flaming them how bad they are and how
> they send all the people with some kind of special needs to the recycle bin.
> I wanted to hear some voices on how to get accessibility on board without
> making extreme effort.
> I stated it from the regulatory/compliance point of view because it is easy
> to give Section 508 or W3C's WCAG recommendation as an example. The American
> government frequently puts Section 508 as a compliance requirement - at
> least it is how it looks like to my knowledge collected from some friends
> working in the software industry in the USA.
> I really enjoyed your comments - especially showing some different angle in
> the placement of accessibility as an UI issue or business issue.
> Thanks a lot,
> Pawel
> ----- Original Message -----
> From: "Stuart Scott"
> Sent: Thursday, March 11, 2010 2:43 PM
> Subject: Re: How would you justify accessibility as an EA/compliance
> requirement.
> >> Those of you who live and work in the United States or Canada may be more
> >> familiar with the terms than people from Asia or Europe.
> > Note that in the UK the whole issue is made simple due to disability
> > discrimination legislation that mandates reasonable efforts to provide
> > accessibility.
> > However, as suggested by other responders, this is merely a subset of
> > the larger suite of requirements around regulatory and compliance
> > needs, and the non-functional demands on any given system (which may
> > include non-IT components).
> > My approach as an EA is generally to treat non-functional requirements
> > such as accessibility, resilience and DR as givens - such requirements
> > don't act as differentiators on any guidance my team provides because
> > we wouldn't put forward an approach that doesn't meet the basic set of
> > requirements.
> > Recommending a single corporate web presence with CMS based microsites
> > on sub-domains incorporating the various transactional web services
> > provided to our customers is a clear and straightforward
> > recommendation with direct customer, marketing, business, cost and IT
> > implications; that it also has to support accessibility requirements
> > doesn't factor in the recommendation.
> > To me, compliance with regulatory needs is owned by the Compliance
> > team; information security by the Infosec team; infrastructure
> > non-functionals by IT. Where accessibility isn't a regulatory
> > requirement then it's a business requirement, and should be owned by
> > the marketing or customer service teams. At most organisations a
> > straightforward business case will be possible highlighting the cost
> > savings provided by direct customer self-service as opposed to hiring
> > additional contact centre staff.
> > For internal employee accessibility I think that's a legal requirement
> > in the US too? It's a more complicated discussion, but not one we need
> > to have in the UK (due to the regulatory requirements).
> > cheers,
> > ~Stuart
TOGAF 9 Certified Level 2 Practitioner
tags
togaf
Name: Joseph George
Date: 24-Mar-2010
Exam: TOGAF 8 - 9 Advanced Bridge via IBT
Result: Pass
Score (%): 90
Status: Certified
CID: 24170
Response: Hack Work
Hack Work, Ian Marchant blog post dt 08/03/2010
Another thing from the Harvard Business Review. The challenge is how do we, as a large company, respond when our IT resources at home or even on our mobile phones are more powerful and flexible than the large corporate systems can be. It seems from the article that our problem is a common one - to quote, "the tools we use in life have leapfrogged over the ones we use at work. Business's lingering love of bureaucracy, process and legacy technology has fallen completely out of sync with what people need to do their best".
The articles solution is to 'hack work' - i.e. rule bending for the good of all. We all do this anyway so why not make it a virtue - "the illusion of corporate control is being shattered in the name of increased personal productivity". We can all think of examples where we have to do things 'outside the system' just to get things done. I know I do and I'm sure there are lots of good examples throughout SSE.
Feedback in response to Ian's Blog
Post Title - Hack Work
Date Posted - 08/03/2010
Name: Joseph George
Department: IT Architecture
Location: Havant
Comments:
Ian,
Thanks for highlighting the challenges we face today. I haven't seen this HBR article you quote, but would very much like to read in entirety.
Some years ago corporate systems had much more oomph than anyone could afford personally. And this discussion wouldn't have happened. The scenario has dramatically changed now.
Our current systems force us to work within constraints set for enforcing mediocre resources to output mediocre quality. It is a sorry state when we find ourselves in a situation where the corporate systems restrict us, rather than enable us to increase personal productivity. And you are quite right that SSE is not in this unique situation, and also that Corporate IT is a product of the business' lingering love of bureaucracy and process. Too much of which makes everything legacy very quickly in this age of incredible business changes happening within extremely short time-scales. I think we should loosen the chains a bit, rather than tightening the noose further. I also refer to your previous blog post. Google and its various products (including mail, calendar, collaboration, etc.), Zoho apps (goes one step further in enabling business productivity), Salesforce and many other cloud products are available everywhere except inside our corporate systems. These products are much cheaper and far more efficient than the legacy technology employed by the business.
You mention "IT resources", where I suspect you refer to physical hardware rather than to value-added services. And I concur that hardware is largely redundant, as any hardware lock-ins are a business risk, which makes physical hardware a white elephant in terms of Capex, Opex, and Security.
Thanks once again for your highly illuminating blog posts, which allow people to widen their thinking horizons. There seems to be some legitimacy to "thinking outside the box", when aided (prompted, supported) by the Chief Exec.
Kind regards,
Joseph
From: Ian Marchant
To: Joseph George
Date: 12/03/2010 16:30
Subject: Re: Hack Work
Sent by: Eilidh Marshall
Joseph,
Thanks for the feedback. Getting the balance right between robustness and routine and the need for agility is a key issue.
Regards,
Ian
TOGAF and Agile Architecture
> I am talking about the changes which need to be seen as to enable short term
> competitive advantage, to be implemented based on the available resources
> I am differentiating it from the architecture needed to grow business.
Interesting... something to ponder about! Is EA better at being tactical for the short term? Or is EA more suitable at being strategic for the medium to long term? This will probably open up another debate in the forum, if I understand right.
I would ask what is the timeframe EA needs to look at. That would also define what "short" term is. It could differ from a few months to a few days depending on who you talk to. The more tactical issues you get involved with - the farther away you move from the decision makers and the decision making process. I would say leave it to the detailed designers to worry about tactical short term issues. This is not for architecture to get involved in. Don't get me wrong - you can't ignore tactical issues.
You are quite right. The current business dynamics are increasing the rate of flux. And IT can't live in history wanting many moons to deliver something. That was yesterday for yesterday's business climate. Which is history now! We need to be radical, yet prudent. If the head is moving fast forward, the tail can't remain stuck in the ground. One solution does not fit all. Some industries are extremely static. But, if you are in a fast moving industry like finance, your architecture needs to be a cultural fit too. If not, your architecture is a failure, possibly becoming a business liability. That was partly what I meant in my previous post.
Kind regards,
Joseph
On Feb 15, 5:57 pm, Mridul wrote:
> Hi Joseph,
> Thanks for the comments.
> I think we need architecture for supporting and stabilizing business. As you
> have mentioned nothing is sustainable in the long run. [with so much
> business dynamics changing every few month]. I have came across
> businesses[like insurance / finance] who have always complained for not able
> to react in time for any change in industry dynamics [environmental change
> or competitor products]. Here an architecture can really help - if it can
> handle these changes.
> I am talking about the changes which need to be seen as to enable short term
> competitive advantage, to be implemented based on the available resources
> I am differentiating it from the architecture needed to grow business.
> On 11 February 2010 22:20, Joseph George < > joseph.geo...@scottish-southern.co.uk> wrote:
> > Mridul,
> > > I had for long believed "EA is a continuous process which align IT with
> > > Business for the purpose of supporting, growing and stabilizing
> > business."
> > > But have now changed it to "EA is a continuous process which align
> > people,
> > > processes and technology with Business for the purpose of supporting,
> > > growing and stabilizing business"\
> > You don't need architecture for supporting or stabilising business. To
> > keep the lights on, just keep doing more of the same. But that might
> > not be sustainable in the long run. In fact, (dare I say) nothing is
> > sustainable to eternity.
> > I would agree with the initial part of your statement that "EA is a
> > continuous process", but would end with "to enable the business".
> > Enable for what? To become "agile"! Agile is remaining competitive, or
> > else the organisation goes stale like yesterday's milk left out in the
> > open.
> > As Adrian says, agile also refers to the business culture, and that is
> > an entirely different ball-game in itself, which architecture can't
> > change on its own. In my experience, architecture reflects the
> > organisational culture. If it's not a match, it won't fit. An agile
> > architecture or an architecture designed for an agile business is not
> > going to stand within a laid-back organisation. This is when skillful
> > leadership in the organisation becomes an asset, and lack-lustre
> > leadership becomes a liability.
> > Best regards,
> > Joseph
> > On Dec 25 2009, 11:21 am, Mridul wrote:
> > > Coming from a IT background, i would like to say. "we do the s/w
> > > developments using agile methodology in cases where the requirements were
> > > not clear[i.e creating a new product, something which the team has not
> > done
> > > before], or doing a research project."
> > > I would say Agile is way to do work. [anyone can define its own agile
> > > methodology] and Scrum is a methodology [defined by PM practitioners]
> > which
> > > is used in s/w development. Using it has its own pros and cons. according
> > to
> > > the Agile advocates [me too] it is best done by a team. where the team
> > does
> > > all the work and delivers, the same team is involved till the end of the
> > > project] the other approach is linear, where different team work in
> > > different phases. For Architecture, [point me if i am wrong] you need
> > > different skill set of people who need to identify scope, do process
> > design,
> > > organize people and functions, do technology designs. The whole TOGAF
> > > framework which is linear in nature can be easily worked out with a
> > linear
> > > approach. Also in Agile the deliverable[partial] done at the end of the
> > > sprint is usable to the client, even if client says no to further
> > > development.
> > > To Bring Agility in EA, the methodology need to be defined. These people
> > are
> > > doing something on Mapping TOGAF to Agile EA.
> >http://agileea.wikidot.com/agile-ea-to-togaf-mapping
> > > I had for long believed "EA is a continuous process which align IT with
> > > Business for the purpose of supporting, growing and stabilizing
> > business."
> > > But have now changed it to "EA is a continuous process which align
> > people,
> > > processes and technology with Business for the purpose of supporting,
> > > growing and stabilizing business"\
> > > Mridul K Singh,
> > > +919899000152
> > > Director,
> > > Thakursahib Tech Consultants.http://www.thakursahib.comhttp://
> >www.linkedin.com/in/mridulksingh
> > > Enterprise Architecture
> > > News
> > > Enterprise Architecture
> > > Jobs
> > > 2009/12/25 Rheinlander Kirk
> > > > You are missing the concept of abstraction - EA is all about
> > abstraction,
> > > > and if technology is the instantiation of the concept, then so be it.
> > If you
> > > > think EA is about technology, you are doing it wrong.
> > > > EA is NOT a design function. It is about coordinating the efforts of a
> > wide
> > > > variety of engineers, in a variety of disciplines, to execute the
> > strategy.
> > > > Damn technologists :-) (guilty as charged, but hopefully, grown beyond
> > that
> > > > narrow point of view!)
> > > > --Kirk
> > > > On Dec 24, 2009, at 12:31 PM, joshua sahala wrote:
> > > > > On Mon, Dec 21, 2009 at 6:48 AM, Rheinlander Kirk
> > > > wrote:
> > > > > [cut]
> > > > >> For that matter, what does technology have to do with enterprise
> > > > >> architecture?
> > > > > everything...technology provides the foundation to everything that a
> > > > > business does.
> > > > >> Technology is just another of the myriad of elements of the
> > enterprise
> > > > that
> > > > >> are part and parcel of enterprise architecture, none more important
> > than
> > > > any
> > > > >> other.
> > > > > if you define technology solely as something that "those people in it
> > > > > want more money to play with", then, imho, you are ignoring the fact
> > > > > that everything you do relies upon technology (and possibly
> > > > > misunderstanding/oversimplifying what technology is).
> > > > > business cannot exist without technology. from the pen and paper
> > that
> > > > > people sometimes still use, to the phone systems that customers call,
> > > > > to the computer that you send your emails from...it is all
> > technology,
> > > > > and pretty much all of it is necessary for a business to survive
> > > > > (though i suppose that you could argue a corner case about certain
> > > > > indigenous populations).
> > > > > i agree, in part, with your viewpoint that ea has been co-opted by
> > > > > subsets (silos) of the business organisation. however, it is
> > > > > disingenous to claim that ea is somehow greater than and/or separate
> > > > > from the technology that a business relies upon (unless of course you
> > > > > are sharing your ea deliverables via an oral tradition only).
> > > > > admittedly my viewpoint is skewed by my background as a technologist,
> > > > > but, i've seen more than a few companies undermine themselves by
> > > > > trying to pretend that "business" decisions have no technological
> > > > > constraints, or by forcing "technology" decisions to be made without
> > > > > technological understanding (if the business decides to only have a
> > > > > hammer, then everything *must* be a nail...). just because an ea can
> > > > > model a business on paper doesn't mean that it is technologically
> > > > > possible to instantiate that model.
> > > > >
> > > > > back to the original question of "can togaf and agile coexist": i
> > > > > agree with the others whom have said yes; providing that the overall
> > > > > structure is in place and doesn't unnecessarily constrain the
> > group(s)
> > > > > that will be using an agile methodology. in other words, understand
> > > > > agile and build it into the overall business process framework
> > > > > with regard to the forward-looking nature (or not) of agile: it is a
> > > > > methodology, and the vision is constrained more by the people
> > involved
> > > > > than by the method itself. if there is a lack of long-term vision
> > > > > going in, then it doesn't matter what method is used, it will lack
> competitive advantage, to be implemented based on the available resources
> I am differentiating it from the architecture needed to grow business.
Interesting... something to ponder about! Is EA better at being tactical for the short term? Or is EA more suitable at being strategic for the medium to long term? This will probably open up another debate in the forum, if I understand right.
I would ask what is the timeframe EA needs to look at. That would also define what "short" term is. It could differ from a few months to a few days depending on who you talk to. The more tactical issues you get involved with - the farther away you move from the decision makers and the decision making process. I would say leave it to the detailed designers to worry about tactical short term issues. This is not for architecture to get involved in. Don't get me wrong - you can't ignore tactical issues.
You are quite right. The current business dynamics are increasing the rate of flux. And IT can't live in history wanting many moons to deliver something. That was yesterday for yesterday's business climate. Which is history now! We need to be radical, yet prudent. If the head is moving fast forward, the tail can't remain stuck in the ground. One solution does not fit all. Some industries are extremely static. But, if you are in a fast moving industry like finance, your architecture needs to be a cultural fit too. If not, your architecture is a failure, possibly becoming a business liability. That was partly what I meant in my previous post.
Kind regards,
Joseph
On Feb 15, 5:57 pm, Mridul
> Hi Joseph,
> Thanks for the comments.
> I think we need architecture for supporting and stabilizing business. As you
> have mentioned nothing is sustainable in the long run. [with so much
> business dynamics changing every few month]. I have came across
> businesses[like insurance / finance] who have always complained for not able
> to react in time for any change in industry dynamics [environmental change
> or competitor products]. Here an architecture can really help - if it can
> handle these changes.
> I am talking about the changes which need to be seen as to enable short term
> competitive advantage, to be implemented based on the available resources
> I am differentiating it from the architecture needed to grow business.
> On 11 February 2010 22:20, Joseph George < > joseph.geo...@scottish-southern.co.uk> wrote:
> > Mridul,
> > > I had for long believed "EA is a continuous process which align IT with
> > > Business for the purpose of supporting, growing and stabilizing
> > business."
> > > But have now changed it to "EA is a continuous process which align
> > people,
> > > processes and technology with Business for the purpose of supporting,
> > > growing and stabilizing business"\
> > You don't need architecture for supporting or stabilising business. To
> > keep the lights on, just keep doing more of the same. But that might
> > not be sustainable in the long run. In fact, (dare I say) nothing is
> > sustainable to eternity.
> > I would agree with the initial part of your statement that "EA is a
> > continuous process", but would end with "to enable the business".
> > Enable for what? To become "agile"! Agile is remaining competitive, or
> > else the organisation goes stale like yesterday's milk left out in the
> > open.
> > As Adrian says, agile also refers to the business culture, and that is
> > an entirely different ball-game in itself, which architecture can't
> > change on its own. In my experience, architecture reflects the
> > organisational culture. If it's not a match, it won't fit. An agile
> > architecture or an architecture designed for an agile business is not
> > going to stand within a laid-back organisation. This is when skillful
> > leadership in the organisation becomes an asset, and lack-lustre
> > leadership becomes a liability.
> > Best regards,
> > Joseph
> > On Dec 25 2009, 11:21 am, Mridul
> > > Coming from a IT background, i would like to say. "we do the s/w
> > > developments using agile methodology in cases where the requirements were
> > > not clear[i.e creating a new product, something which the team has not
> > done
> > > before], or doing a research project."
> > > I would say Agile is way to do work. [anyone can define its own agile
> > > methodology] and Scrum is a methodology [defined by PM practitioners]
> > which
> > > is used in s/w development. Using it has its own pros and cons. according
> > to
> > > the Agile advocates [me too] it is best done by a team. where the team
> > does
> > > all the work and delivers, the same team is involved till the end of the
> > > project] the other approach is linear, where different team work in
> > > different phases. For Architecture, [point me if i am wrong] you need
> > > different skill set of people who need to identify scope, do process
> > design,
> > > organize people and functions, do technology designs. The whole TOGAF
> > > framework which is linear in nature can be easily worked out with a
> > linear
> > > approach. Also in Agile the deliverable[partial] done at the end of the
> > > sprint is usable to the client, even if client says no to further
> > > development.
> > > To Bring Agility in EA, the methodology need to be defined. These people
> > are
> > > doing something on Mapping TOGAF to Agile EA.
> >http://agileea.wikidot.com/agile-ea-to-togaf-mapping
> > > I had for long believed "EA is a continuous process which align IT with
> > > Business for the purpose of supporting, growing and stabilizing
> > business."
> > > But have now changed it to "EA is a continuous process which align
> > people,
> > > processes and technology with Business for the purpose of supporting,
> > > growing and stabilizing business"\
> > > Mridul K Singh,
> > > +919899000152
> > > Director,
> > > Thakursahib Tech Consultants.http://www.thakursahib.comhttp://
> >www.linkedin.com/in/mridulksingh
> > > Enterprise Architecture
> > > News
> > > Enterprise Architecture
> > > Jobs
> > > 2009/12/25 Rheinlander Kirk
> > > > You are missing the concept of abstraction - EA is all about
> > abstraction,
> > > > and if technology is the instantiation of the concept, then so be it.
> > If you
> > > > think EA is about technology, you are doing it wrong.
> > > > EA is NOT a design function. It is about coordinating the efforts of a
> > wide
> > > > variety of engineers, in a variety of disciplines, to execute the
> > strategy.
> > > > Damn technologists :-) (guilty as charged, but hopefully, grown beyond
> > that
> > > > narrow point of view!)
> > > > --Kirk
> > > > On Dec 24, 2009, at 12:31 PM, joshua sahala wrote:
> > > > > On Mon, Dec 21, 2009 at 6:48 AM, Rheinlander Kirk
> > > > wrote:
> > > > > [cut]
> > > > >> For that matter, what does technology have to do with enterprise
> > > > >> architecture?
> > > > > everything...technology provides the foundation to everything that a
> > > > > business does.
> > > > >> Technology is just another of the myriad of elements of the
> > enterprise
> > > > that
> > > > >> are part and parcel of enterprise architecture, none more important
> > than
> > > > any
> > > > >> other.
> > > > > if you define technology solely as something that "those people in it
> > > > > want more money to play with", then, imho, you are ignoring the fact
> > > > > that everything you do relies upon technology (and possibly
> > > > > misunderstanding/oversimplifying what technology is).
> > > > > business cannot exist without technology. from the pen and paper
> > that
> > > > > people sometimes still use, to the phone systems that customers call,
> > > > > to the computer that you send your emails from...it is all
> > technology,
> > > > > and pretty much all of it is necessary for a business to survive
> > > > > (though i suppose that you could argue a corner case about certain
> > > > > indigenous populations).
> > > > > i agree, in part, with your viewpoint that ea has been co-opted by
> > > > > subsets (silos) of the business organisation. however, it is
> > > > > disingenous to claim that ea is somehow greater than and/or separate
> > > > > from the technology that a business relies upon (unless of course you
> > > > > are sharing your ea deliverables via an oral tradition only).
> > > > > admittedly my viewpoint is skewed by my background as a technologist,
> > > > > but, i've seen more than a few companies undermine themselves by
> > > > > trying to pretend that "business" decisions have no technological
> > > > > constraints, or by forcing "technology" decisions to be made without
> > > > > technological understanding (if the business decides to only have a
> > > > > hammer, then everything *must* be a nail...). just because an ea can
> > > > > model a business on paper doesn't mean that it is technologically
> > > > > possible to instantiate that model.
> > > > >
> > > > > back to the original question of "can togaf and agile coexist": i
> > > > > agree with the others whom have said yes; providing that the overall
> > > > > structure is in place and doesn't unnecessarily constrain the
> > group(s)
> > > > > that will be using an agile methodology. in other words, understand
> > > > > agile and build it into the overall business process framework
> > > > > with regard to the forward-looking nature (or not) of agile: it is a
> > > > > methodology, and the vision is constrained more by the people
> > involved
> > > > > than by the method itself. if there is a lack of long-term vision
> > > > > going in, then it doesn't matter what method is used, it will lack
Subscribe to:
Posts (Atom)