Zero-based Budgeting[1]
It's a story that plays out across industry sectors and change efforts, particularly in this age of digital transformation. Companies embark on a project intending to optimise every existing process.
Showing posts with label business.architecture. Show all posts
Showing posts with label business.architecture. Show all posts
Zero-based Budgeting and ZBO
tags
business.architecture,
change,
culture,
design,
strategy
Greg Smith's resignation letter
Greg Smith - Executive Director, Goldman Sachs
Today is my last day at Goldman Sachs. After almost 12 years at the firm — first as a summer intern while at Stanford, then in New York for 10 years, and now in London — I believe I have worked here long enough to understand the trajectory of its culture, its people and its identity. And I can honestly say that the environment now is as toxic and destructive as I have ever seen it.
To put the problem in the simplest terms, the interests of the client continue to be sidelined in the way the firm operates and thinks about making money. Goldman Sachs is one of the world’s largest and most important investment banks and it is too integral to global finance to continue to act this way. The firm has veered so far from the place I joined right out of college that I can no longer in good conscience say that I identify with what it stands for.
It might sound surprising to a skeptical public, but culture was always a vital part of Goldman Sachs’s success. It revolved around teamwork, integrity, a spirit of humility, and always doing right by our clients. The culture was the secret sauce that made this place great and allowed us to earn our clients’ trust for 143 years. It wasn’t just about making money; this alone will not sustain a firm for so long. It had something to do with pride and belief in the organization. I am sad to say that I look around today and see virtually no trace of the culture that made me love working for this firm for many years. I no longer have the pride, or the belief.
But this was not always the case. For more than a decade I recruited and mentored candidates through our grueling interview process. I was selected as one of 10 people (out of a firm of more than 30,000) to appear on our recruiting video, which is played on every college campus we visit around the world. In 2006 I managed the summer intern program in sales and trading in New York for the 80 college students who made the cut, out of the thousands who applied.
I knew it was time to leave when I realized I could no longer look students in the eye and tell them what a great place this was to work.
When the history books are written about Goldman Sachs, they may reflect that the current chief executive officer, Lloyd C. Blankfein, and the president, Gary D. Cohn, lost hold of the firm’s culture on their watch. I truly believe that this decline in the firm’s moral fiber represents the single most serious threat to its long-run survival.
Over the course of my career I have had the privilege of advising two of the largest hedge funds on the planet, five of the largest asset managers in the United States, and three of the most prominent sovereign wealth funds in the Middle East and Asia. My clients have a total asset base of more than a trillion dollars. I have always taken a lot of pride in advising my clients to do what I believe is right for them, even if it means less money for the firm. This view is becoming increasingly unpopular at Goldman Sachs. Another sign that it was time to leave.
How did we get here? The firm changed the way it thought about leadership. Leadership used to be about ideas, setting an example and doing the right thing. Today, if you make enough money for the firm (and are not currently an ax murderer) you will be promoted into a position of influence.
What are three quick ways to become a leader? a) Execute on the firm’s “axes,” which is Goldman-speak for persuading your clients to invest in the stocks or other products that we are trying to get rid of because they are not seen as having a lot of potential profit. b) “Hunt Elephants.” In English: get your clients — some of whom are sophisticated, and some of whom aren’t — to trade whatever will bring the biggest profit to Goldman. Call me old-fashioned, but I don’t like selling my clients a product that is wrong for them. c) Find yourself sitting in a seat where your job is to trade any illiquid, opaque product with a three-letter acronym.
Today, many of these leaders display a Goldman Sachs culture quotient of exactly zero percent. I attend derivatives sales meetings where not one single minute is spent asking questions about how we can help clients. It’s purely about how we can make the most possible money off of them. If you were an alien from Mars and sat in on one of these meetings, you would believe that a client’s success or progress was not part of the thought process at all.
It makes me ill how callously people talk about ripping their clients off. Over the last 12 months I have seen five different managing directors refer to their own clients as “muppets,” sometimes over internal e-mail. Even after the S.E.C., Fabulous Fab, Abacus, God’s work, Carl Levin, Vampire Squids? No humility? I mean, come on. Integrity? It is eroding. I don’t know of any illegal behavior, but will people push the envelope and pitch lucrative and complicated products to clients even if they are not the simplest investments or the ones most directly aligned with the client’s goals? Absolutely. Every day, in fact.
It astounds me how little senior management gets a basic truth: If clients don’t trust you they will eventually stop doing business with you. It doesn’t matter how smart you are.
These days, the most common question I get from junior analysts about derivatives is, “How much money did we make off the client?” It bothers me every time I hear it, because it is a clear reflection of what they are observing from their leaders about the way they should behave. Now project 10 years into the future: You don’t have to be a rocket scientist to figure out that the junior analyst sitting quietly in the corner of the room hearing about “muppets,” “ripping eyeballs out” and “getting paid” doesn’t exactly turn into a model citizen.
When I was a first-year analyst I didn’t know where the bathroom was, or how to tie my shoelaces. I was taught to be concerned with learning the ropes, finding out what a derivative was, understanding finance, getting to know our clients and what motivated them, learning how they defined success and what we could do to help them get there.
My proudest moments in life — getting a full scholarship to go from South Africa to Stanford University, being selected as a Rhodes Scholar national finalist, winning a bronze medal for table tennis at the Maccabiah Games in Israel, known as the Jewish Olympics — have all come through hard work, with no shortcuts. Goldman Sachs today has become too much about shortcuts and not enough about achievement. It just doesn’t feel right to me anymore.
I hope this can be a wake-up call to the board of directors. Make the client the focal point of your business again. Without clients you will not make money. In fact, you will not exist. Weed out the morally bankrupt people, no matter how much money they make for the firm. And get the culture right again, so people want to work here for the right reasons. People who care only about making money will not sustain this firm — or the trust of its clients — for very much longer.
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
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.
EA value measures ? who cares?
tags
business.architecture,
tea.net
Graham,
> I am not convinced that EA has much input to strategy as currently
> deployed by most companies , the savings come frequently from IT,
> such as server or applications consolidation , none of which is
> actually business strategy. Business is comprised of several
> disciplines such as Strategy, Planning , Operational execution ,
> Resource management , finance and more latterly Information
> technology . EA rarely addresses any of these , its simply an
> enabler in one or more of them.
As currently practised, EA does not have much input into strategy. In a ideal world, strategy would be formulated based on EA recommendations. But, EA needs to mature and move up the food-chain for that to happen. As I see it, EA seems to be getting dragged into creating lower and lower level details, possibly because it is trying to be everything for everyone.
One of the goals of EA is to increase the Operational Efficiencies, and for that EA needs to focus on where the bulk of the expenditure (CAPEX, OPEX,...) is spent on. Guess where that might be? That is probably what needs to be sorted and where massive savings could be gained.
From what I have seen, EA would always be an enabler! If I could *tell* my CEO to do something, then I become more than an enabler... But, I guess, I am a long way off from there... Others might be in much better positions?
Best regards,
Joseph
On 6 June, 20:12, Rheinlander Kirk wrote:
> As the organizations create the content of the enterprise
> architecture, by default, they agree to it.
> EA just allows communication and coordination across the boundaries,
> so they know the right things to do.
> Yes, I cut and pasted a relevant paragraph, rather than retyping the
> text again, as it had meaning in both contexts.
> On Jun 6, 2009, at 3:43 AM, C Johnson wrote:
> > I know where you are coming from, however for this context, if one
> > does not have a view (or baseline) of the organisations
> > architecture, then one cannot govern it... where the EA team owns
> > the process or references it, the business still need to understand
> > and agree that the architecture follows what they have and what they
> > see for the future (i.e. objectives, goals)
> I am not convinced that EA has much input to strategy as currently
> deployed by most companies , the savings come frequently from IT,
> such as server or applications consolidation , none of which is
> actually business strategy. Business is comprised of several
> disciplines such as Strategy, Planning , Operational execution ,
> Resource management , finance and more latterly Information
> technology . EA rarely addresses any of these , its simply an
> enabler in one or more of them.
As currently practised, EA does not have much input into strategy. In a ideal world, strategy would be formulated based on EA recommendations. But, EA needs to mature and move up the food-chain for that to happen. As I see it, EA seems to be getting dragged into creating lower and lower level details, possibly because it is trying to be everything for everyone.
One of the goals of EA is to increase the Operational Efficiencies, and for that EA needs to focus on where the bulk of the expenditure (CAPEX, OPEX,...) is spent on. Guess where that might be? That is probably what needs to be sorted and where massive savings could be gained.
From what I have seen, EA would always be an enabler! If I could *tell* my CEO to do something, then I become more than an enabler... But, I guess, I am a long way off from there... Others might be in much better positions?
Best regards,
Joseph
On 6 June, 20:12, Rheinlander Kirk
> As the organizations create the content of the enterprise
> architecture, by default, they agree to it.
> EA just allows communication and coordination across the boundaries,
> so they know the right things to do.
> Yes, I cut and pasted a relevant paragraph, rather than retyping the
> text again, as it had meaning in both contexts.
> On Jun 6, 2009, at 3:43 AM, C Johnson wrote:
> > I know where you are coming from, however for this context, if one
> > does not have a view (or baseline) of the organisations
> > architecture, then one cannot govern it... where the EA team owns
> > the process or references it, the business still need to understand
> > and agree that the architecture follows what they have and what they
> > see for the future (i.e. objectives, goals)
Who is a business architect?
tags
business.architecture,
tea.net
Eswar,
> But, what is then the role of business architect - if his role is to
> just help by creating or understanding 'business' information, does
> he/she really involved in business decision making?
I think you query is relevant to all disciplines of Architecture and not just Business Architects. Everywhere I have been and seen, the Architects are not usually the decision makers, although they get deeply involved in the decision making process. The final decision (and responsibility) lies with the domain owners. If you are talking business, the business owners *are* the decision makers. Same applies to technology and other domains. The architect might make decisions, but that would always be on behalf of the domain owners. The architect recommends, along with his justifications based on their understanding. Note that the architect's understanding might not be complete, and they might not be privy to everything.
Also, the architect is not responsible for creating (or implementing) the organisation or any of its systems, and as such is further removed from the responsibility of ownership.
Best regards,
Joseph
On 17 June, 10:44, Eswar Ganesan wrote:
> The reason I have asked this question has an direct impact on the
> 'role of business architect'. The answer seems to be that all these
> combinations of roles I have provided are kind of 'yes' for the role
> of business architect.
> But, what is then the role of business architect - if his role is to
> just help by creating or understanding 'business' information, does
> he/she really involved in business decision making?
> If one is to be involved in business decision making, then there is a
> need to appreciate the business motivation - the row 1 of Zachmann.
> How can a business architect be able to model or identify business
> strategy has he not participated in strategy formulation or corporate
> planning and be able to drive business needs?
> Is business architect, just a consultant who cannot make decisions and
> is there only to provide the information the business management and
> operating team would like to have leading them to create informed
> decision making? This question might answer who can be a good business
> architect.
> Regards,
> Eswar
> On Wed, Jun 17, 2009 at 7:39 AM, Douglas Erickson wrote:
> > Wrong! Enterprise Architecture is the discipline of defining, designing,
> > and constructing the infrastructure for an enterprise. This includes the
> > the data, business processes to be performed, the geographic and
> > organizational structure of the enterprise, etc. An Enterprise Architect is
> > a person who is knowledgeable, skilled, and has expertise indefining,
> > designing, and developing and Enterprise. ENTERPRISE ARCHITECTURE HAS NEVER
> > BEEN ABOUT JUST THE TECHNOLOGY INFRASTUCTURE OF AN ENTERPRISE. That would
> > be, at best, an Information Technology Architect, or just a Technology
> > Architect which would only deal with Rows 3-5, of Column 3 of the Zachman
> > Enterprise Framework.
> > A Business Architect, if there is such a thing is the operating management
> > of the enterprise, the decision-makers, planners, etc.
> > ----- Original Message -----
> > From: Steve Cohen
> > To: the-enterprise-architecture-network@googlegroups.com
> > Sent: Tuesday, June 16, 2009 7:15 PM
> > Subject: Re: Who is a business architect?
> > In my opinion a Business Architect is someone who helps structure the
> > business (operating model, organizational structure, sizing, etc) to best
> > meet the already defined corporate / SBU / BU strategy - including making
> > best use of the software tools available.
> > An Enterprise Architect structures the technology to best enable the
> > business architecture.
> > Their background can come from multiple places
> > Eswar Ganesan said the following on 6/16/2009 9:08 AM:
> > Hi,
> > I have the following questions:
> > 1) Is BA is a person who has considerable amount of experience (more
> > than 10 years) in business decision making - have been part of
> > strategy development and corporate planning and finally turned out to
> > be architect advising/consulting EA initiatives of organizations?
> > 2) Is BA is Business Analyst turned Architect (more like technical
> > analyst/system analyst turned IT Architect) over a standard amount of
> > experience (5 + years) in business analysis, requirements engineering
> > and process modeling?
> > 3) Is BA is a "management consultant" who has knowledge/capabilities
> > on helping organizations/business units decide their strategic
> > objectives; a person with considerable amount (5+ years) of experience
> > in appreciating business motivation (goal/objective/strategy/tactics),
> > business situation (market trends, economic conditions etc) and
> > business project management?
> > 4) Is he a IT project manager turned BA over a considerable amount of
> > experience (12+years) in handling multiple IT projects/application
> > releases? A person who can appreciate business needs and IT delivery?
> > 5) An EA who has performed business architecture, application
> > architecture, information architecture and technology architecture for
> > a considerable amount of time (10 + years) and currently consults for
> > BA?
> > 6) Or simply a BA is an internal resource of the organization who is
> > groomed by the EA program or participated heavily on business decision
> > making and corporate planning as well financial planning functions?
> > Who is Business Architect..........
> > Regards,
> > Eswar
> But, what is then the role of business architect - if his role is to
> just help by creating or understanding 'business' information, does
> he/she really involved in business decision making?
I think you query is relevant to all disciplines of Architecture and not just Business Architects. Everywhere I have been and seen, the Architects are not usually the decision makers, although they get deeply involved in the decision making process. The final decision (and responsibility) lies with the domain owners. If you are talking business, the business owners *are* the decision makers. Same applies to technology and other domains. The architect might make decisions, but that would always be on behalf of the domain owners. The architect recommends, along with his justifications based on their understanding. Note that the architect's understanding might not be complete, and they might not be privy to everything.
Also, the architect is not responsible for creating (or implementing) the organisation or any of its systems, and as such is further removed from the responsibility of ownership.
Best regards,
Joseph
On 17 June, 10:44, Eswar Ganesan
> The reason I have asked this question has an direct impact on the
> 'role of business architect'. The answer seems to be that all these
> combinations of roles I have provided are kind of 'yes' for the role
> of business architect.
> But, what is then the role of business architect - if his role is to
> just help by creating or understanding 'business' information, does
> he/she really involved in business decision making?
> If one is to be involved in business decision making, then there is a
> need to appreciate the business motivation - the row 1 of Zachmann.
> How can a business architect be able to model or identify business
> strategy has he not participated in strategy formulation or corporate
> planning and be able to drive business needs?
> Is business architect, just a consultant who cannot make decisions and
> is there only to provide the information the business management and
> operating team would like to have leading them to create informed
> decision making? This question might answer who can be a good business
> architect.
> Regards,
> Eswar
> On Wed, Jun 17, 2009 at 7:39 AM, Douglas Erickson
> > Wrong! Enterprise Architecture is the discipline of defining, designing,
> > and constructing the infrastructure for an enterprise. This includes the
> > the data, business processes to be performed, the geographic and
> > organizational structure of the enterprise, etc. An Enterprise Architect is
> > a person who is knowledgeable, skilled, and has expertise indefining,
> > designing, and developing and Enterprise. ENTERPRISE ARCHITECTURE HAS NEVER
> > BEEN ABOUT JUST THE TECHNOLOGY INFRASTUCTURE OF AN ENTERPRISE. That would
> > be, at best, an Information Technology Architect, or just a Technology
> > Architect which would only deal with Rows 3-5, of Column 3 of the Zachman
> > Enterprise Framework.
> > A Business Architect, if there is such a thing is the operating management
> > of the enterprise, the decision-makers, planners, etc.
> > ----- Original Message -----
> > From: Steve Cohen
> > To: the-enterprise-architecture-network@googlegroups.com
> > Sent: Tuesday, June 16, 2009 7:15 PM
> > Subject: Re: Who is a business architect?
> > In my opinion a Business Architect is someone who helps structure the
> > business (operating model, organizational structure, sizing, etc) to best
> > meet the already defined corporate / SBU / BU strategy - including making
> > best use of the software tools available.
> > An Enterprise Architect structures the technology to best enable the
> > business architecture.
> > Their background can come from multiple places
> > Eswar Ganesan said the following on 6/16/2009 9:08 AM:
> > Hi,
> > I have the following questions:
> > 1) Is BA is a person who has considerable amount of experience (more
> > than 10 years) in business decision making - have been part of
> > strategy development and corporate planning and finally turned out to
> > be architect advising/consulting EA initiatives of organizations?
> > 2) Is BA is Business Analyst turned Architect (more like technical
> > analyst/system analyst turned IT Architect) over a standard amount of
> > experience (5 + years) in business analysis, requirements engineering
> > and process modeling?
> > 3) Is BA is a "management consultant" who has knowledge/capabilities
> > on helping organizations/business units decide their strategic
> > objectives; a person with considerable amount (5+ years) of experience
> > in appreciating business motivation (goal/objective/strategy/tactics),
> > business situation (market trends, economic conditions etc) and
> > business project management?
> > 4) Is he a IT project manager turned BA over a considerable amount of
> > experience (12+years) in handling multiple IT projects/application
> > releases? A person who can appreciate business needs and IT delivery?
> > 5) An EA who has performed business architecture, application
> > architecture, information architecture and technology architecture for
> > a considerable amount of time (10 + years) and currently consults for
> > BA?
> > 6) Or simply a BA is an internal resource of the organization who is
> > groomed by the EA program or participated heavily on business decision
> > making and corporate planning as well financial planning functions?
> > Who is Business Architect..........
> > Regards,
> > Eswar
Response: What's your policy idea?
tags
business.architecture,
change,
marchant,
policy
What's your policy idea?, Ian Marchant blog post dt 15/06/2009
...
Feedback in response to Ian's Blog
Post Title - What's your policy idea?
Date Posted - 15/06/2009
Name: Joseph George
Department: Technical Solutions
Location: Havant
Comments:
Ian,
I would propose a tiered tariff, much like the tax bands, but more. The lowest band would have the least cost per unit, and the upper bands would have progressively higher unit costs. This would mean that someone would pay much more for the 1000th unit than what he would pay for the 1st unit.
Currently, we (the industry) penalise low users with a standing charge load.
Kind regards,
Joseph
From: Ian Marchant
To: Joseph George
Date: 25/06/2009 16:50
Subject: Re: What's your policy idea?
Sent by: Eilidh Marshall
Joseph
We have been discussing this concept - so called rising block tariff with Ofgem and Government for some time now and one day I expect we will be successful.
Ian
Response: Why SSE exists
Why SSE exists, Ian Marchant blog post dt 09/06/2009
...
Feedback in response to Ian's Blog
Post Title - Why SSE exists
Date Posted - 30/04/2009
Name: Joseph George
Department: Technical Solutions
Location: Havant
Comments:
Ian,
Thank you so much for letting us have your speech. Your 10 Commandments (sorry Recommendations) touched a chord, particularly the (1st Commandment) statement: "We are not interested in getting people to use more of our product. It’s about selling them what they need – not what they can be persuaded they want." This reminded me of one of my enterprise architecture (internet peer group) forum conversations in Jan this year. I will reproduce some snippets of my comments from that conversation below:
<snip>
</snip>
I don't agree that "business is about making money" only. A few months ago, I would have been hard pressed to explain this. Look at the financial hotch-potch around you. If making money is the sole reason for a business, that will eventually destroy the economy.
Business is about providing a service and realising a value for it, not all in monetary terms either, but much of it so. Making money is tangential. A business justifies its existence in the Food-Chain by value-adding, and not by removing some existing ones. I would challenge even those people who say that their only reason for living is to make money. They perhaps do not realise that they might want to be happy too, as also to want to safely spend that money they have made not by losing it on some other greedy (criminal?) money making business, destroying the economy, society and associated eco-systems.
<snip>
</snip>
I do stand by my previous statement, as I have explained, and will happily explain again. However, I was not talking about a "green" company or a charity or some sort of voluntary organisation. If we look at the values or the mission statement of any commercial company worth its salt, we might notice that none of them put making money at the top of their list.
I would be happy to be proven wrong. Please don't get me wrong... I am not against making money, or have that as an objective. Money is important!
What am against is making money the sole objective or mission, as that leads to overiding any values or morals, which would otherwise be a decision making factor. It is not sustainable...
For this reason, I don't consider working for some industries... Perhaps that is my wishful thinking. But I don't wish to contribute to any nefarious business actively (overtly or covertly) going about destroying what people live for.
I believe your speech should be released to all our employees via their manager's team-brief, and let everyone digest these. I don't think every employee is able to read your blog.
Kind regards,
Joseph
Architecture Consolidation
Benjamin,
If each of your businesses and business units "are following certain Architecture framework and have implementation using the defined architecture", then I would say that you have won the war. You are only left with the small battles. It doesn't matter what framework you are using. All the frameworks do is provide you a view of the existing data.
My understanding of the answers you are looking for are:
1. Translating or transforming your data held in one framework to another should be relatively easy, as long as you have all the i's dotted and t's crossed. If you find it difficult, use a tool. We use Casewise, which provides various plug-ins for various frameworks. Use the appropriate plug-in, and you see your architecture in a familiar framework. You are not changing the data, only the view.
2. Ahh.... Now, this is the crux of Enterprise Architecture - consolidate, rationalise and standardise. If you have completed the Enterprise Architecture, it should have laid out your to-be enterprise, with an understanding of where your execs want to take the business. If you have EAs for each SBU, lay them side-by-side or in layers one-on-top, which should straight away tell you what you need.
3. Do your Gap Analysis. I prefer the top-down approach. Identify the changes needed to your Business Architecture, which should drive the changes necessary to your Information Architecture, which should drive the changes required to your Technology Architecture, and so on...
Kind regards,
Joseph
On Sep 29, 7:25 am, Benjamin wrote:
> Hi,
> I am having this thought for quite a long time, regarding Architecture
> Consolidation for a large Enterprise (Having multiple sub-
> organizations under its arm).
> I would like to have inputs on the ways and means for Architecture
> Consolidation. Let me give the scenario - An Enterprise X has multiple
> sub-division across the globe. These sub-divisions (A small
> organization in its own way) are following certain Architecture
> framework and have implementation using the defined architecture. Now
> for Enterprise X, it has multiple Architecture framework spread
> across.
> My question to all:
> 1. How can Enterprise X plan to have Architectural Consolidation so
> that all its child organization follow same Architectural framework
> 2. How can Enterprise X address the difference among Architecture?
> 3. If there is any agreement for Common Architecture, then how one
> should plan for the migration to the new Architecture
> Thanks;
> Benjamin
If each of your businesses and business units "are following certain Architecture framework and have implementation using the defined architecture", then I would say that you have won the war. You are only left with the small battles. It doesn't matter what framework you are using. All the frameworks do is provide you a view of the existing data.
My understanding of the answers you are looking for are:
1. Translating or transforming your data held in one framework to another should be relatively easy, as long as you have all the i's dotted and t's crossed. If you find it difficult, use a tool. We use Casewise, which provides various plug-ins for various frameworks. Use the appropriate plug-in, and you see your architecture in a familiar framework. You are not changing the data, only the view.
2. Ahh.... Now, this is the crux of Enterprise Architecture - consolidate, rationalise and standardise. If you have completed the Enterprise Architecture, it should have laid out your to-be enterprise, with an understanding of where your execs want to take the business. If you have EAs for each SBU, lay them side-by-side or in layers one-on-top, which should straight away tell you what you need.
3. Do your Gap Analysis. I prefer the top-down approach. Identify the changes needed to your Business Architecture, which should drive the changes necessary to your Information Architecture, which should drive the changes required to your Technology Architecture, and so on...
Kind regards,
Joseph
On Sep 29, 7:25 am, Benjamin
> Hi,
> I am having this thought for quite a long time, regarding Architecture
> Consolidation for a large Enterprise (Having multiple sub-
> organizations under its arm).
> I would like to have inputs on the ways and means for Architecture
> Consolidation. Let me give the scenario - An Enterprise X has multiple
> sub-division across the globe. These sub-divisions (A small
> organization in its own way) are following certain Architecture
> framework and have implementation using the defined architecture. Now
> for Enterprise X, it has multiple Architecture framework spread
> across.
> My question to all:
> 1. How can Enterprise X plan to have Architectural Consolidation so
> that all its child organization follow same Architectural framework
> 2. How can Enterprise X address the difference among Architecture?
> 3. If there is any agreement for Common Architecture, then how one
> should plan for the migration to the new Architecture
> Thanks;
> Benjamin
Subscribe to:
Posts (Atom)