Search Results for: systems development life cycle SDLC

How to build better systems – the specification

by

We probably can all agree that defining functional and non-functional requirements are the most critical elements of a project’s success or failure. Reducing specification requirements errors is the single most effective action we can take to improve project outcomes. The approach I propose is inexpensive and mitigates much of the risk associated with defects and errors early in the development life cycle.

Glossary

by

A collection of Enterprise Architecture terms and definitions from a variety of sources: EA3 Cube, Introduction to Enterprise Architecture, The Common Approach to Federal Enterprise Architecture (FEAF-II), ISO 42010:2011 and TOGAF 9. 00

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

by
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. 

Where did the Business Analysts go? 
The change of focus was probably, in part, caused by the rise in enterprise software packages and the associated promise that these out­-of­-the-­box solutions could work miracles – magically automating all kinds of business processes and spraying efficiency glitter over all parts of the organisation. Powerful promises! 
And to make them even more seductive, they contrasted sharply with often, expensive and unsatisfactory, custom­-build software projects. Small wonder then, the new-kids-on-the-block, ­ERP packages,­ were seen as being more business relevant: enforcing standardisation and promising to boost efficiency. Business Analysts started to abandon their ‘real job’ to become, in effect, package ‘fit­-and­-configuration’ specialists. Inevitably, their work began to focus on the features and functions of the software, rather than the realities of the business with its complexities: messy processes and human interactions. 
Since then, others with expertise in IS, have gravitated to the world of IT architecture. This discipline has proved increasingly important with the many large organisations who realise that packages – even so called ‘enterprise-­wide’ ones, need to coexist the rest of the IT estate. You can’t buy architecture in-a-box!
At the same time, the revolution in Open Source and Web technologies meant that the focus of architecture began to move away from the organisation’s internal IS needs and towards the emerging global IT standards, tools and methods used by its customers, suppliers and partners. The sheer complexity of all aspects of ‘architecture’ meant that areas of technology­-focused specialism began to develop within the architecture community. 
This article suggests, it’s time to dust-off the concept of Information Systems, and return to  business analysis practice that focuses on:
Simplifying [as much as makes-sense], balancing  and consolidating requirements across all aspects of  the business, but with, the important business outcomes, front­-of­-mind. 
Identifying repeating patterns of business activity and seeking out opportunities for shared competencies and services. 
Understanding the behavioural aspects of the business that have been proven to be barriers to adoption of IT solutions. 
Studying the elementary aspects of the business’s Information System such as rules and constraints embedded in policies, the business­-meaningful, real­-world, events of interest and the information content being exchanged between individuals and groups. 
Communicating and agreeing upon the business ‘what’ before getting immersed in the technology ‘how’. 

What’s in a Word? The Problem with ‘Process’ 

There appears to be a problem with how we use the word ‘process’. To support business efficiency goals, many envisage the world as a set of neatly ordered, well planned, pre­determined and logically sequenced set of activities – just as Henry Ford did when he introduced the production line. This is hardly surprising as it is a tried and tested approach to manufacturing, and more generally reflects a simple but intelligent goal – to be more efficient at a task through understanding and optimising all the steps. However, optimisation and automation require all the steps and parties involved to be specifically defined, so this approach usually seeks to ‘decompose’ the task into detailed models of all the interacting parts within the end­-to-­end process. The process being defined is also typically mapped to an organisational framework and financial models which constrain it within central and departmental rules, polices and edicts, which are often inherited from corporate decisions unrelated to the process in-­hand. This is Six-Simga-Everything mentality! The most critical problem with this efficency-only focus, is in its  poor representation of the softer, more knotty problems associated with differing values, policies, and operational ‘realities’.
To add to this problem, the language of users differs significantly from that of the IT specialist. This difference in language is a reflection of apparently opposing values (value systems) in play. Fundamentally, the users want a system that works the way they do ­one which is often prone to change and which supports learning. The IT specialist seeks a high degree of functional certainty and actionable rules that can be configured or encoded. 
(see note about ‘Agile’ SDLC at little later).

To make matters worse, the gaps and inconsistencies in the expression of business requirements force a high degree of IT ‘engineering rigour’ that attempts to complete the picture. IT engineering relies upon techniques and tools that are designed to convert process and policy into precise rules and constraints. This can result in important behavioural dimensions ­such as the effect of variance in values and levels of trust – being left unspecified, and tension-points left unresolved. The dialogue between user and the IT specialist becomes focused on the detailed features and functions of the IT ‘solution’. The business outcomes of the sponsoring executive become obscured by this drive towards detail and by the end-users’ individual, and collective, ideas on how the ‘solution’ will work. 
C-level ‘Businesss Stakeholder Standardisation Edicts’ or sent out in an attempt to ‘Get Things Back on Track’: ensure that operational efficiency goals are met and key business outcomes are delivered. This can result in an unwitting collusion between the C-level ‘Business Stakeholder’ and the IT specialist: both parties are motivated to build ‘standardised’ behaviour into the IT solution.

The top­-down edict approach to driving IT­-enabled business change projects suffers from three major problems: 

Adoption Barriers ­ 
The users are less inclined to adopt the IT solution, claiming that it doesn’t work for them – they continue to use and develop ‘shadow’ IT solutions 
Brittle Processes ­
The top­-down specification of process works against flexibility and becomes a barrier to future business change. 

Business/IT Misalignment ­
The organisational and management models of the business are not properly reflected in the IT solution. In, for example, a multinational business with diverse operations, it may be necessary and desirable to allow for local freedom­-to­-act, in say, Customer-facing processes. 
It seems we need a different approach to how we specify requirements for IT: an approach that balances the desired business outcomes of the stakeholder with the needs of the user, yet with the precision needed by the IT specialist. 

Significant improvements are being claimed by the ‘Agile’ development  community, however, the problem still exists when likes of SCRUM and XP don’t apply, such as the deployment of a package solution or, increasingly, the purchase of SaaS. Not to mention, that  ‘Agile’ approaches can be left wanting when in comes to cyber-security and data privacy.

It appears that the language-used, and a premature focus on IT, are at the root of this problem.  The language problem starts with how we express the concept of processes.  The word ‘process’ can have very different meanings and implications. These can range from the loose collection of unsystematic activities, that might support a contract negotiation, or an HR process, to the highly repetitious, and predetermined behaviour, of say, a production line. Maybe a common language for describing the range of business behaviour, across any type of process, would help?
A premature obsession with the details of the IT solution, seems to drive the analysis of the business problem towards IT engineering methods. Such methods often ignore or, at best, neglect softer, human, aspects. IT engineering methods and techniques are designed to drive completeness and precision for systems and, in doing so, introduce a language that is, by its nature, hard for the business to understand. This creates frustration on both sides of the Business/IT divide: neither party understanding the needs of the other.  The sheer volume of information produced during the engineering life­-cycle, means the overall business context gets lost in the production of  flow diagrams and technical plans. The complexity of the task requires a high degree of technical specialism. This can lead to a lack of focus on the nuances of real-world behaviour and human interaction ‘on­-the-ground’. Often the focus is slanted towards engineering ‘How’ rather than the business ‘What’: the business outcome. 
The reality is that many business scenarios are more organic, and unpredictable, than  pre-determinable, and mechanistic. In today’s connected world, many business scenarios encounter tensions ­ between corporate and local functions, between customer and supplier, and between partners. No one is in control of the end­ end processes; rather, a combination of interacting service agreements make up the overall value delivered to the customer. 
In contrast to usual business/IT dialogues, what’s needed is a natural-language that moves the focus away from any technologies and towards business behaviour – as expressed in values, policies, real­-world events and any type of information [Content] being exchanged.  

The original article bangs-on about VPEC-T and, our then, current, book ‘Lost In Translation‘, which I’ll skip now [sigh of relief for many!]. I would end the article differently now.  In hindsight, it missed-out some more fundamental (and frankly, more broadly applicable techniques) such as SWOT, Risk-Radar, Hypothesis-led and PESTLE analysis. Perhaps more importantly, I would emphasise the value of; ‘abstraction’ (conceptual and logical ‘What’ before ‘How’ thinking), an understanding of ‘Complex Systems’ – The Cynefin Model (Dave Snowden) would be a good starting point –  and  workshop techniques such as those described in ‘Gamestorming‘ (Dave Gray, Sunni Brown and James Macanufo).
I recently came across the ‘Brown Cow Model‘  (Suzanne & James Robertson) when wrestling with a culture of ‘How’ before ‘What’ behaviour  – aka ‘I have the solution, so what’s the problem’ ! I love the simplicity of ‘Brown Cow’:

I’ve found this simple model a great way to keep project teams focused on understanding the ‘What’ before the ‘How’ and the importance of knowing the AS-IS situation before leaping to the TO-BE. This, for example, has opened-up the requirements discussion to include the, often-overlooked, business requirements of the transition between ‘Now’ and ‘Future’ states. Maybe, this is more of a problem here in Asia, but given some experiences I had in the UK over the past five years, I suspect not!

 I about to run out of battery on my iPad now – so that’s all for now. As always, I ask for your comments! Thx.

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

by
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. 

Where did the Business Analysts go? 
The change of focus was probably, in part, caused by the rise in enterprise software packages and the associated promise that these out­-of­-the-­box solutions could work miracles – magically automating all kinds of business processes and spraying efficiency glitter over all parts of the organisation. Powerful promises! 
And to make them even more seductive, they contrasted sharply with often, expensive and unsatisfactory, custom­-build software projects. Small wonder then, the new-kids-on-the-block, ­ERP packages,­ were seen as being more business relevant: enforcing standardisation and promising to boost efficiency. Business Analysts started to abandon their ‘real job’ to become, in effect, package ‘fit­-and­-configuration’ specialists. Inevitably, their work began to focus on the features and functions of the software, rather than the realities of the business with its complexities: messy processes and human interactions. 
Since then, others with expertise in IS, have gravitated to the world of IT architecture. This discipline has proved increasingly important with the many large organisations who realise that packages – even so called ‘enterprise-­wide’ ones, need to coexist the rest of the IT estate. You can’t buy architecture in-a-box!
At the same time, the revolution in Open Source and Web technologies meant that the focus of architecture began to move away from the organisation’s internal IS needs and towards the emerging global IT standards, tools and methods used by its customers, suppliers and partners. The sheer complexity of all aspects of ‘architecture’ meant that areas of technology­-focused specialism began to develop within the architecture community. 
This article suggests, it’s time to dust-off the concept of Information Systems, and return to  business analysis practice that focuses on:
Simplifying [as much as makes-sense], balancing  and consolidating requirements across all aspects of  the business, but with, the important business outcomes, front­-of­-mind. 
Identifying repeating patterns of business activity and seeking out opportunities for shared competencies and services. 
Understanding the behavioural aspects of the business that have been proven to be barriers to adoption of IT solutions. 
Studying the elementary aspects of the business’s Information System such as rules and constraints embedded in policies, the business­-meaningful, real­-world, events of interest and the information content being exchanged between individuals and groups. 
Communicating and agreeing upon the business ‘what’ before getting immersed in the technology ‘how’. 

What’s in a Word? The Problem with ‘Process’ 

There appears to be a problem with how we use the word ‘process’. To support business efficiency goals, many envisage the world as a set of neatly ordered, well planned, pre­determined and logically sequenced set of activities – just as Henry Ford did when he introduced the production line. This is hardly surprising as it is a tried and tested approach to manufacturing, and more generally reflects a simple but intelligent goal – to be more efficient at a task through understanding and optimising all the steps. However, optimisation and automation require all the steps and parties involved to be specifically defined, so this approach usually seeks to ‘decompose’ the task into detailed models of all the interacting parts within the end­-to-­end process. The process being defined is also typically mapped to an organisational framework and financial models which constrain it within central and departmental rules, polices and edicts, which are often inherited from corporate decisions unrelated to the process in-­hand. This is Six-Simga-Everything mentality! The most critical problem with this efficency-only focus, is in its  poor representation of the softer, more knotty problems associated with differing values, policies, and operational ‘realities’.
To add to this problem, the language of users differs significantly from that of the IT specialist. This difference in language is a reflection of apparently opposing values (value systems) in play. Fundamentally, the users want a system that works the way they do ­one which is often prone to change and which supports learning. The IT specialist seeks a high degree of functional certainty and actionable rules that can be configured or encoded. 
(see note about ‘Agile’ SDLC at little later).

To make matters worse, the gaps and inconsistencies in the expression of business requirements force a high degree of IT ‘engineering rigour’ that attempts to complete the picture. IT engineering relies upon techniques and tools that are designed to convert process and policy into precise rules and constraints. This can result in important behavioural dimensions ­such as the effect of variance in values and levels of trust – being left unspecified, and tension-points left unresolved. The dialogue between user and the IT specialist becomes focused on the detailed features and functions of the IT ‘solution’. The business outcomes of the sponsoring executive become obscured by this drive towards detail and by the end-users’ individual, and collective, ideas on how the ‘solution’ will work. 
C-level ‘Businesss Stakeholder Standardisation Edicts’ or sent out in an attempt to ‘Get Things Back on Track’: ensure that operational efficiency goals are met and key business outcomes are delivered. This can result in an unwitting collusion between the C-level ‘Business Stakeholder’ and the IT specialist: both parties are motivated to build ‘standardised’ behaviour into the IT solution.

The top­-down edict approach to driving IT­-enabled business change projects suffers from three major problems: 

Adoption Barriers ­ 
The users are less inclined to adopt the IT solution, claiming that it doesn’t work for them – they continue to use and develop ‘shadow’ IT solutions 
Brittle Processes ­
The top­-down specification of process works against flexibility and becomes a barrier to future business change. 

Business/IT Misalignment ­
The organisational and management models of the business are not properly reflected in the IT solution. In, for example, a multinational business with diverse operations, it may be necessary and desirable to allow for local freedom­-to­-act, in say, Customer-facing processes. 
It seems we need a different approach to how we specify requirements for IT: an approach that balances the desired business outcomes of the stakeholder with the needs of the user, yet with the precision needed by the IT specialist. 

Significant improvements are being claimed by the ‘Agile’ development  community, however, the problem still exists when likes of SCRUM and XP don’t apply, such as the deployment of a package solution or, increasingly, the purchase of SaaS. Not to mention, that  ‘Agile’ approaches can be left wanting when in comes to cyber-security and data privacy.

It appears that the language-used, and a premature focus on IT, are at the root of this problem.  The language problem starts with how we express the concept of processes.  The word ‘process’ can have very different meanings and implications. These can range from the loose collection of unsystematic activities, that might support a contract negotiation, or an HR process, to the highly repetitious, and predetermined behaviour, of say, a production line. Maybe a common language for describing the range of business behaviour, across any type of process, would help?
A premature obsession with the details of the IT solution, seems to drive the analysis of the business problem towards IT engineering methods. Such methods often ignore or, at best, neglect softer, human, aspects. IT engineering methods and techniques are designed to drive completeness and precision for systems and, in doing so, introduce a language that is, by its nature, hard for the business to understand. This creates frustration on both sides of the Business/IT divide: neither party understanding the needs of the other.  The sheer volume of information produced during the engineering life­-cycle, means the overall business context gets lost in the production of  flow diagrams and technical plans. The complexity of the task requires a high degree of technical specialism. This can lead to a lack of focus on the nuances of real-world behaviour and human interaction ‘on­-the-ground’. Often the focus is slanted towards engineering ‘How’ rather than the business ‘What’: the business outcome. 
The reality is that many business scenarios are more organic, and unpredictable, than  pre-determinable, and mechanistic. In today’s connected world, many business scenarios encounter tensions ­ between corporate and local functions, between customer and supplier, and between partners. No one is in control of the end­ end processes; rather, a combination of interacting service agreements make up the overall value delivered to the customer. 
In contrast to usual business/IT dialogues, what’s needed is a natural-language that moves the focus away from any technologies and towards business behaviour – as expressed in values, policies, real­-world events and any type of information [Content] being exchanged.  

The original article bangs-on about VPEC-T and, our then, current, book ‘Lost In Translation‘, which I’ll skip now [sigh of relief for many!]. I would end the article differently now.  In hindsight, it missed-out some more fundamental (and frankly, more broadly applicable techniques) such as SWOT, Risk-Radar, Hypothesis-led and PESTLE analysis. Perhaps more importantly, I would emphasise the value of; ‘abstraction’ (conceptual and logical ‘What’ before ‘How’ thinking), an understanding of ‘Complex Systems’ – The Cynefin Model (Dave Snowden) would be a good starting point –  and  workshop techniques such as those described in ‘Gamestorming‘ (Dave Gray, Sunni Brown and James Macanufo).
I recently came across the ‘Brown Cow Model‘  (Suzanne & James Robertson) when wrestling with a culture of ‘How’ before ‘What’ behaviour  – aka ‘I have the solution, so what’s the problem’ ! I love the simplicity of ‘Brown Cow’:

I’ve found this simple model a great way to keep project teams focused on understanding the ‘What’ before the ‘How’ and the importance of knowing the AS-IS situation before leaping to the TO-BE. This, for example, has opened-up the requirements discussion to include the, often-overlooked, business requirements of the transition between ‘Now’ and ‘Future’ states. Maybe, this is more of a problem here in Asia, but given some experiences I had in the UK over the past five years, I suspect not!

 I about to run out of battery on my iPad now – so that’s all for now. As always, I ask for your comments! Thx.

The Agile Enterprise Value Chain

by

Agile methods have not been widely adopted by enterprises. Agile projects remain, for the most part, independent software development activities, and often by design focused on key areas of enterprise innovation. The latter makes sense, but we should question why Agile concepts should not be rolled out more broadly, because there are considerable opportunities for process improvement across wider range of project classes as well as greater coverage of the end to end life cycle.

If we take this broader, multidimensional view, it should also help enterprises to take a more mature position on agile and agility. Agile methods are primarily guiding management and to an extent project management practices. The business value focus is therefore not surprisingly on “project” quality, cycle time and cost. If we take a broader view we can also focus on enterprise level business improvement, governance and end to end process optimization.

Nobody wants to overload an Agile delivery process unnecessarily. But there are key enterprise perspectives that need to be addressed, and good way to figure out which contribute to the overall delivered agility is to model business value. The business value model allows us to a) develop and refine the solution delivery value chain required for varying enterprise and project contexts and b) charter (structure, manage, govern) architecture and delivery projects with greater probability of achieving optimal outcomes. 

Naturally all enterprises and projects have varying needs for business value. Yes, fastest cycle time and lowest cost are always important, but we can imagine that these will be reasonably compromised for the right business improvement, or reduced risk. A good place to start therefore is by considering the agility related business value required for a project, scenario or enterprise in its broadest sense and relate this to delivery life cycle outcomes. In the simple model below I have listed some practice domains and potential outcomes and then mapped these to candidate business benefits.
Agile Outcomes Mapped to Business Value (Example Fragment)
I have focused Agile practices on Lean process values because these seem to encapsulate all the various Agile methods. In addition I have included disciplines that focus on typical enterprise activities including architecture, asset management, application lifecycle management and automation. I don’t pretend this list is exhaustive, it’s merely illustrative. I am sure readers will have many ideas for practice domains and relevant outcomes. I then mapped this starter list against business benefits using the very effective approach that I cribbed from COBIT5 when I was developing extensions of same. FYI P: Primary, S: Secondary.

This analysis then provides structured data on which to develop an agility value chain (diagram below). I’m sure readers will be very familiar with this technique, first described by Michael Porter[1].  For further explanation see my introduction in Realizing the Agile Enterprise.
Agile Enterprise Value Chain
There are some key points to make about the agile value chain:
1. The primary activities are a cohesive set of activities, and it is important to optimize value across the entire life cycle. For example:
– Addressing software development alone is likely to be suboptimal.
– Making sure that demand is understood, grounded in business strategy, aggregated across lines of business and geographies where appropriate, decomposed into optimal units of work, consolidated into units of release and so on is key.
– Establishing clarity of purpose and matching with an optimal delivery approach.
– Integrating the activities of architecture, definition and delivery in a continuous value chain that minimizes architecture and definition efforts based on value creation. 

2. The value of primary activities can be dramatically enhanced with good supporting activity.

3. That supporting capabilities may be delivered using primary activities which either have qualified goals and objectives, or that the outcomes of primary activities are harvested to create supporting capabilities. For example, in the typical enterprise there are frequently considerable benefits to be gained from reusing many types of asset such as  services, components, schema,  platforms, patterns etc. but it is relatively unusual for enterprises to capitalize on these opportunities for a multitude of reasons including politics, budgets, ownership and support. However if the potential value can be demonstrated and quantified in terms of reduced delivery times and costs, then a business case can be made to put effective systems put in place. 

4. Agile concepts do not just relate to software development! There is great opportunity to adopt key Agile concepts including particularly Lean, Kanban and Scrum, across the entire delivery value chain, particularly for primary activities such as demand and define, and supporting activities such as governance, architecture and delivery infrastructure.

5. That few enterprises are independent, and collaborations are part of business as usual. Further, innovative forms of collaboration may be actively pursued relative to the enterprise’s goals, which might result in widespread use of a common platform, business or technology services, or involvement of unconventional partners such as brokers or social networks.

The Value Chain provides a framework for analyzing the relative business value of the capabilities involved in product delivery in terms of agility outcomes.  In the table below I have shown just a small fragment of what this might look like. I have decomposed each Value Chain Activity into capabilities and assessed potential agility outcomes. Some very obvious extensions would be to include scoring (weighted support to business level benefits) plus inter capability dependencies. A logical conclusion might be to quantify value in terms of cycle time hours or cost reduction, but this seems unnecessary for our purpose here.

Capabilities Mapped to
Agility Outcomes  (Example Fragment)
The detailed Value Chain provides a structured basis for creating and communicating delivery life cycle templates. And it occurs to me this could be just the way to address the elephant in the room for many enterprises – the SDLC standard, commonly a formally mandated standard that is all but ignored by most projects. For most enterprises I believe there are just three basic delivery patterns which provide three template choices, and I will expand on these shortly. I will also be discussing all of the value chain activities in some detail.
Talk to Everware-CBDIabout the Agile Enterprise Workshop. This is currently available as an in-house, intensive workshop. Public scheduled classes will hopefully follow next year.

[1] Porter, M.E. (1985) Competitive Advantage, Free Press, New York, 1985.

10 Ways to be More Agile

by

Print PDF Written with contributions from Michael Mariani, Tim Mattix, Ryan Finnamore and many others. You might think the word “agile” is synonymous with “paralysis” to see some organizations react to the idea of introducing agile development principles to their traditional systems development lifecycle (SDLC). Concerns about introducing too much change to the organization can stop agility discussions with the business before they start. But if the organization’s goals include increasing the speed of development, […]

If you liked this, you might also like:

  1. Are Agile and CMMI Compatible?
  2. The Agile CIO as a Business – IT Marriage Counselor
  3. Is Agile an “All or Nothing” Proposition?

When effort estimations feel like buying showroom kitchens

by

Purchasing a showroom kitchen can be an unpleasant experience, especially if you’re not sure of the value of what you are buying. Kitchen showrooms tend to have the atmosphere of a prestigious car dealership, perhaps because the price tag of a well-designed kitchen is similar to a mid-sized car. If you happen to linger at […]

Gaming, Visualization, Simulation and Optimization: A New Reality for Enterprise Architecture

by

  I think that the push for considering an alternative means to engage in EA is, indeed, already underway. In organizations who treat “people as strategy” (e.g., SEMCO, Whole Foods, HCL, Topcoder), wherein people are give broad self-directed control of creating and executing strategy in real time, the notion that one will “translate business vision […]

The post Gaming, Visualization, Simulation and Optimization: A New Reality for Enterprise Architecture appeared first on Philip Allega.

Gaming, Visualization, Simulation and Optimization: A New Reality for Enterprise Architecture

by

  I think that the push for considering an alternative means to engage in EA is, indeed, already underway. In organizations who treat “people as strategy” (e.g., SEMCO, Whole Foods, HCL, Topcoder), wherein people are give broad self-directed control of creating and executing strategy in real time, the notion that one will “translate business vision […]