entarch

What Happened to the Fine Art of Business Analysis? – Revisited 2013

by

Link: http://taotwits-too-big-to-tweet.blogspot.com/2013/05/what-happened-to-fine-art-of-business.html

From Taotwit's Too-Big-To-Tweet

Back in 2008, I wrote a paper on Business Analysis. Recently, I’ve been revisiting this subject in my day-job and this made me realise how little things had changed and inspired me to write this post, which is, basically, the original article re-written, with additional thoughts (in italics).

The role of the Business Analyst has never been more important but needs refocus on Information Systems not the technical solution. Many of us can recall a time when a distinction was made between the hardware and software supporting the business and the information used by the business – there was a clear difference between IT, to describe the former, and IS to describe the latter. 
IS stood for Information Systems: 
IS: The landscape  of business  information used by people within an organisation 
and how they use information to deliver business outcomes. 

IT, in contrast, meant: 
IT:  The  hardware  and  software  technology  that  automates  or  otherwise  supports 
information processing. 

This distinction between these two concepts is all but lost, and the disciplines associated with Information Systems (such as Business Analysis and IS Architecture), are have become too obsessed with IT. 

Read more

0

What Happened to the Fine Art of Business Analysis? – Revisited 2013

by

Link: http://taotwits-too-big-to-tweet.blogspot.com/2013/05/what-happened-to-fine-art-of-business.html

From Taotwit's Too-Big-To-Tweet

Back in 2008, I wrote a paper on Business Analysis. Recently, I’ve been revisiting this subject in my day-job and this made me realise how little things had changed and inspired me to write this post, which is, basically, the original article re-written, with additional thoughts (in italics).

The role of the Business Analyst has never been more important but needs refocus on Information Systems not the technical solution. Many of us can recall a time when a distinction was made between the hardware and software supporting the business and the information used by the business – there was a clear difference between IT, to describe the former, and IS to describe the latter. 
IS stood for Information Systems: 
IS: The landscape  of business  information used by people within an organisation 
and how they use information to deliver business outcomes. 

IT, in contrast, meant: 
IT:  The  hardware  and  software  technology  that  automates  or  otherwise  supports 
information processing. 

This distinction between these two concepts is all but lost, and the disciplines associated with Information Systems (such as Business Analysis and IS Architecture), are have become too obsessed with IT. 

Read more

0

Your org as an api #openwork

by

 

 

What if your organisation’s internal business processes had a publicly accessible api?

What if information about the internals of your products and services where available to mine, interact with and influence?

How would that change your customer’s perception of your organisation?

Would your customer’s self organise?

Would they help you improve your organisation?

Would your customer’s uncover insight you didn’t know you even wanted?

How would transparency of your organisations strengths and weakness change how you and your competitors operate

What would prevent such a leap? the thought of airing your dirty laundry? losing competitive advantage?

Wouldn’t it be great to not have dirty laundry?

Would radical openness and the necessary re-orientation of the organisation towards its customers bring a whole new competitive advantage?

Lots of questions, I don’t have the answers at the moment. If this post sparks any thoughts i’d love to continue the conversation either on twitter or in the comments on this post.

The value of lenses

by

image

TOGAF

Zachman

Agile

Scrum

Kanban

XP

User centred design

Lean

Lean startup

Service design

Design thinking

Behavioural economics

What do these things have in common? These are all things I’m either interested in, read a lot about, studied/got certified in, or use/have used in my work.

The other thing that they have in common? None of these things are The answer.

I like to think of each of the list above as lenses that help you view problems in a different way, using them individually or in combination can help inform your view of the problem space and give you greater options when looking for solutions.

It is very tempting for us to find a methodology or framework that resonates with us at a point in time (for me back in 2006, it was Scrum) and start to see everything through that particular lense.

There is a danger in relying on one lense too much and that in focusing on the use of one lense we become myopic, concentrating on using our chosen methodology/framework/process without understanding its application in the context of the wider problem space.

Example:

A few months ago I attended the excellent @SyncNorwich monthly conference. One speaker gave a talk about using Kanban on a software development project. It was a really informative talk about using Kanban on a project, the team seemed to work really well, the ‘product owner’ seemed happy and they shipped early and often. It all sounded great until the speaker put up a slide showing the tiny amount of usage/sales of the product.

I was left with the conclusion that using the lense of Kanban had enabled the team to deliver the wrong thing really really well. The weak link in the chain was whatever design process the Product Owner (and his team) used to feed into the development process.

I raised this conclusion with the speaker, he didn’t seem to think it was his problem (or Kanban’s). The fact that the organisation he worked for had ploughed (i’d estimate) several hundred thousand pounds into developing products that customers didn’t use, didn’t seem to register as a problem. His team had delivered what his customer (the Product Owner) required using Kanban, worrying about what the real customer actually wanted wasn’t even on his radar. The net result was the customer’s needs weren’t met. Whatever lense we decide to use the needs of the customer should always be in plain sight.

TOGAF Good or Bad? – Definitely Ugly!

by

I’m struggling with the value of TOGAF on my current assignment.

Background:


·        We have a need to develop architectural thinking up the ‘food-chain’ to the C-level to help inform business strategy.

·        The IT Leadership want to focus on: agility & resilience (fast response and ability to thrive under constant change), security, value-for-money and continuously improving User Experience

.

·        Unusually for a private company, we are not currently focused on competition (we are a monopoly) nor inefficiency (labour cost – we rarely ‘let people go’).


·        We have established business-engaged governance mechanisms around Cyber Threat, however, there’s cultural resistance to Western-style Governance practices and methods in other areas.


·        The IT department is mostly seen as a Cost Centre, although we are making some progress here.


·        English is the second language for the vast majority of our employees.


·        Experienced Enterprise Architects are rarer than hen’s teeth in Hong Kong.


·        A few on my team have been trained and ‘Certified’ in TOGAF (mostly before I joined) but they have not actually practiced EA (for a wide variety of reasons) since attending the course.

Observations:


·        TOGAF is hard to comprehend for those whose 1st language is English, so it’s an even greater challenge for my team.

·        TOGAF just tries too hard and ends up failing on a few counts; it’s too comprehensive to be a usable framework and not specific enough to be a methodology. It’s almost a philosophy, but a very incomplete and, at times, dangerously misleading one. This is very hard for my team to make sense of and I find myself having very long conversations with them where we end up agreeing that we reduce or focus on one or two of the TOGAF concepts (usually around a deliverable).

·        TOGAF doesn’t seem to help very much when it comes to the challenges we face around Consumer-led IT.

·        TOGAF does encourage SOA, that would help our agility & resilience goal eventually, but we’re quite a way from developing a genuine component-based, shared-services architecture due to the business organisation, culture and funding mechanisms. And we can’t wait for those to change to be able meet our agility & resilience needs.

·        It’s fair to say,TOGAF training does help introduce newbies to some important EA perspectives and does help with common terms and concepts, but it requires a lot of additional buddy-work with an experienced architect to become useful and, what’s worse, it conveys the wrong message; ‘Enterprise Architecture is complicated and requires a high intellectual capacity to understand’. The latter being the absolute opposite of what I need to convey across IT and the business; ‘Enterprise Architecture is about joining-the-dots and making things simpler to understand’.

I do continue to put my team through TOGAF Certification. Why? It’s the only credible option here getting newbies up-to-speed on the basics of EA/SA and it helps my staff build their CVs (which is important). I just wish there was a better option that was both less and more:



and


  • more – on the basic mentality required of of an EA (e.g ability to abstract) and why all organizations take a different approach to architecture based on culture, maturity and business priorities.

I sometimes wonder if the authors of TOGAF are motivated to make it more understandable, or, as seems to be the case, keep it obscure and arcane. It certainly felt that way when I was exposed to IAF (Capgemini’s Framework) and its zealots for the first time.

An aside here: in a recent chat with the Chief Architect in a well-known travel company, I said I needed the 80 page version of TOGAF – he laughed and responded that he’d implemented an 8 page version! BTW: all his architects are native-English speakers hired in from abroad.

TOGAF Good or Bad? – Definitely Ugly!

by

I’m struggling with the value of TOGAF on my current assignment.

Background:


·        We have a need to develop architectural thinking up the ‘food-chain’ to the C-level to help inform business strategy.

·        The IT Leadership want to focus on: agility & resilience (fast response and ability to thrive under constant change), security, value-for-money and continuously improving User Experience

.

·        Unusually for a private company, we are not currently focused on competition (we are a monopoly) nor inefficiency (labour cost – we rarely ‘let people go’).


·        We have established business-engaged governance mechanisms around Cyber Threat, however, there’s cultural resistance to Western-style Governance practices and methods in other areas.


·        The IT department is mostly seen as a Cost Centre, although we are making some progress here.


·        English is the second language for the vast majority of our employees.


·        Experienced Enterprise Architects are rarer than hen’s teeth in Hong Kong.


·        A few on my team have been trained and ‘Certified’ in TOGAF (mostly before I joined) but they have not actually practiced EA (for a wide variety of reasons) since attending the course.

Observations:


·        TOGAF is hard to comprehend for those whose 1st language is English, so it’s an even greater challenge for my team.

·        TOGAF just tries too hard and ends up failing on a few counts; it’s too comprehensive to be a usable framework and not specific enough to be a methodology. It’s almost a philosophy, but a very incomplete and, at times, dangerously misleading one. This is very hard for my team to make sense of and I find myself having very long conversations with them where we end up agreeing that we reduce or focus on one or two of the TOGAF concepts (usually around a deliverable).

·        TOGAF doesn’t seem to help very much when it comes to the challenges we face around Consumer-led IT.

·        TOGAF does encourage SOA, that would help our agility & resilience goal eventually, but we’re quite a way from developing a genuine component-based, shared-services architecture due to the business organisation, culture and funding mechanisms. And we can’t wait for those to change to be able meet our agility & resilience needs.

·        It’s fair to say,TOGAF training does help introduce newbies to some important EA perspectives and does help with common terms and concepts, but it requires a lot of additional buddy-work with an experienced architect to become useful and, what’s worse, it conveys the wrong message; ‘Enterprise Architecture is complicated and requires a high intellectual capacity to understand’. The latter being the absolute opposite of what I need to convey across IT and the business; ‘Enterprise Architecture is about joining-the-dots and making things simpler to understand’.

I do continue to put my team through TOGAF Certification. Why? It’s the only credible option here getting newbies up-to-speed on the basics of EA/SA and it helps my staff build their CVs (which is important). I just wish there was a better option that was both less and more:



and


  • more – on the basic mentality required of of an EA (e.g ability to abstract) and why all organizations take a different approach to architecture based on culture, maturity and business priorities.

I sometimes wonder if the authors of TOGAF are motivated to make it more understandable, or, as seems to be the case, keep it obscure and arcane. It certainly felt that way when I was exposed to IAF (Capgemini’s Framework) and its zealots for the first time.

An aside here: in a recent chat with the Chief Architect in a well-known travel company, I said I needed the 80 page version of TOGAF – he laughed and responded that he’d implemented an 8 page version! BTW: all his architects are native-English speakers hired in from abroad.