Search Results for: business model

Your enterprise and social media?! We’ve got an IDEA!

by

Social media is indispensable from the organizational environment. Where people collaborate interaction exists and since society’s large-scale adoption of the internet, social media shaped online conversations about, with and within organizations. Social media is a fact of life; it is no longer the question whether an organization should use social media, but how they should use it. However, research by Gartner shows that most social media initiatives fail to achieve participation from the community or to achieve any meaningful purpose. So why do some organizations fail in using social media, while others – for instance KLM – are extremely successful in it? I think because many organizations do not understand the importance of adequately incorporating social media initiatives within their organizational structure. They do not know how to use social media in the context of their enterprise and become a ‘Social Enterprise’.

Designing the Social Enterprise

I strongly believe in a sort of ‘manufacturability’ of organizations. With manufacturability I mean designing the organization(al change) by the use of business models, enterprise architecture and process management. These are the fundamentals of delivering customer value in an effective and efficient way (although more than just these disciplines is required). I think that social media should be subject to these disciplines too. Maybe social media is not that ‘manufacturable’ as a business process or architecture, in the end it is part of a ‘social system’ about which we should carefully think why and how we participate in it. It is indeed the field in which most of our customers (internal or external to our organization) are active. That’s why social media offers us great opportunities and hazards for creating and delivering customer value.

IDEA for the Social Enterprise

In the consortium project ‘New Models for the Social Enterprise’ we designed ‘IDEA for the Social Enterprise’. IDEA is an abbreviation for the Interactive Design and Engineering Approach. It offers a method – with its roots in design thinking – to incorporate social media in your organization. By several diverging and converging phases we propose coherent instruments which help you to understand the value of social media in relation to your business model, the related business processes and the customers.

To conclude: whether you like it or not, social media is one of the trends we cannot deny from a perspective of organizational design. Social media has become an important channel for creating and delivering customer value. In order to use social media in delivering optimal customer value, I am convinced that organizations need a good IDEA about how to integrate social media in their enterprise!

If you have any questions or interest in IDEA or our research project ‘New models for the Social Enterprise’, feel free to contact me at b.beuger@bizzdesign.nl

Categories Uncategorized

Does anonymity promote ill-informed consensus?

by

There are a spate of new Social Media apps that have emerged lately, all of which allow people to post comments and ideas anonymously.  They are being quickly adopted, especially among the very important 13-18 year old “adolescent market.”  They are also being quickly banned for promoting cyberstalking, cyberbullying, and otherwise cruel behavior.  Does anonymity protect cruelty?  And what does that say about more established Anonymous sites, like Wikipedia?

Normally I don’t comment on Social Media.  My regular readers know that I tend to focus primarily on enterprise architectural concerns like business model viability and strategic alignment.  But there is an interesting cross-over between Enterprise Architecture and Social Media, especially anonymous social media: the creation of community consensus.

The state of anonymity

For those not keeping up, there is a spate of new social media apps that have emerged lately, from Whisper to Secret to Yik Yak, that allow smartphone users to sign up and then post messages unfiltered and anonymously.  When in anonymous mode, users tend to say things that they feel uncomfortable saying on Twitter or Facebook (where their friends, family, and coworkers may discover a side of them that they may not agree with). 

YikYak especially is troubling because it uses a geolocation filter… you can see things posted by people within a certain distance of you.  Sounds innocent, right?  After all, young adults filtering through Bourbon Street festivities in New Orleans could share that a particular bar was playing really good jazz, or that drinks are strong and cheap across the street.  But you may quickly see the problem when I use two words: middle school.  Already, some High Schools and Middle Schools have had to ban the app because it became a platform for bullying and cruel comments.

The effects of anonymity

But what does it mean to be anonymous?  What are these comments that the guy next to you would like to send to “the world” without anyone knowing it was him?

You can look for yourself at Whisper.sh.  I spent a few minutes browsing through some of today’s messages.  Most were simple secrets… many were sexual or related to dating.  Some were work related.  Most had responses from equally anonymous people, and most were fairly benign.  Of course, there could be some judicious editing going on for the sake of casual surfers like me that own a Windows phone (and therefore can’t use the app).  Secret and Yik Yak don’t even make an effort to show any of their messages on their website.  It’s all in the app (once again, only for IPhone or, in the case of YikYak, android).

Of these, I think Yik Yak is the most interesting from a consensus point of view, because it is the only one that attempts to filter according to a community.  GeoLocation, especially when it comes to universities or even small towns, is sure to limit the reach of a message to people who share something in common with you.  That sense of “sharing something in common” is really what defines a community, and consensus only really matters in a community.

Anonymity and consensus

Does anonymity work to create consensus?  Sure.  Think of standing in a large crowd.  If one person yells something, you don’t normally turn to them and identify the source before considering, and possibly agreeing with, the content.  This is the very essence of a political rally or a protest march.  Taking in unfiltered ideas and deciding on them, on the spot, is part of how consensus is built.  Of course, there is no good way to take in ONLY good ideas when you are in a crowd.  We count on the crowd to do that for us.  If someone in a political rally yells “Death to the other guys!” we would expect the folks standing next to them to react, possibly causing the rabble-rouser to back down.  (Unless your protest march is in Karachi or Tehran or Cairo… but that’s another post).

In that sense, standing in a crowd is only “partially” anonymous.  There are still people who can see you, and if you do something really outrageous, there are people who could react by hitting you.  This is why you won’t find many people who will go to a crowded Yom Kippur (Jewish) service and stand up in the middle of the crowd and yell “Hitler was right!”  Pandemonium. 

But consensus and anonymity online is very different than standing in a crowd, and I think we need to be aware of the differences. 

The perils of anonymity online

Online, you can make claims that are difficult for another person to dispel, without consequence at all.  There is no one next to you ready to elbow you when you use name calling, or circulate unfounded rumors, or simply make things up!  Even when we use our actual names, we may participate in a discussion where we are not in the same room, or even the same continent, as our peers, and this can cause problems.

I cannot count the number of times I’ve witnessed this on LinkedIn.  A person will ask a question about frameworks, and I may point them to PEAF (a framework created by Kevin Smith).  No problem.  But if Kevin himself gets on the thread and mentions PEAF, his messages are blocked and he may even be kicked out of the discussion.  Why?  Because someone somewhere made a spurious charge (that he makes money when you use PEAF, which is not true).  Since the administrators of most LinkedIn Groups are anonymous, they can make bad decisions without consequence.  There is no good way for Kevin to clear his name of these charges because he does not know who the administrators are, and they appear unwilling to consider the possibility that he is not, in fact, using the platform to promote his own self interests.  Rumor rules the roost.  Not good.

I believe that the same thing applies to Wikipedia. 

Wikipedia, with its millions of articles, has emerged as one of the chief sources of encyclopedic content on the Internet.  It is widely respected, and most search engines make a point of returning Wikipedia entries near the top of their search results.  However, the administrators on Wikipedia are mostly anonymous.  (They use pseudonyms to do their editing work). 

This causes the same problems to occur in Wikipedia that occur in any other setting where people can be anonymous… mostly benign behavior with occasional outburst of bad behavior (with nearly no consequence). 

There is an essay (not a policy) on Wikipedia that says “Only Martians Should Edit.”  This policy says that some topics are so controversial that anyone associated with the actual content would be too biased to edit the content in a neutral manner.  Therefore, topics dealing with such things as State or Provincial politics, or national boundary disputes, or whether specific historic events should be counted as a genocide.  These things trigger strong emotions, so having people edit the articles as though they are “from Mars” can be a good policy.

On the other hand, for some topics that are very narrow, it is not possible to edit the article without knowledge of the subject.  If you are not an expert in African pop music, you may not do a good job discussing Azonto music and dance from Ghana.  In this case, an editor with no grounding in the subject is likely to make mistakes. 

The problem is that Wikipedia is based on consensus, and you may find yourself editing a page on Wikipedia where you have to build consensus among anonymous people, people that may or may not have ANY understanding of the subject matter.  And those people can be nice, or cruel, with no consequence.  There is no one in the crowd next to them ready to elbow them for making an outrageous statement… because the other editors don’t know if the statement is outrageous!  You can build credibility on how well you enforce the rules, and then use that credibility to attack someone, and no one else can tell the difference.

Anonymity: Handle With Care

I’m of the opinion that anonymity on the Internet has to be handled with care.  There are times when it is necessary, especially when attempting to avoid governmental or organized oppression to free speech.  On the other hand, there are times when it is a license for ill-informed people to promote nonsense as a consensus.  After all, one third of Louisiana Republicans have been misled into thinking that Obama is to blame for the poor response to Hurricane Katrina.  I can think of a other examples of an ill-fated consensus among the ill-informed, but rarely one so laughable.

I believe that Sites and Apps should not leverage anonymity as a feature.  I make exceptions for Tahrir Square and Occupy Wall Street, etc, where rumor may be the only information you can trust, but that is not what these apps do. For normal social interactions, anonymity is actually a problem.  On Wikipedia, I believe that anonymity has outlived its usefulness. 

Oh No! We need another Practice Framework?

by

A few years ago I commented [in Beware the New Silos, ref 1 below] that in a complicated world we cope by specialization – and across the industry in general and in individual enterprises specifically we have created silos of our primary disciplines. The widely used frameworks and methods illustrate that common practice of discipline centricity. We don’t have to look too far for examples such as Enterprise Architecture (TOGAF), Governance (Cobit), SOA (separately by OASIS, OMG, Open Group), Agile methods (many and various), Business Process Management (BPM) and IT Service Management (ITIL). All of these disciplines, whether de jure or de facto standards, are all very narrowly focused with minimal treatment of how the disciplines might work together.

A good example is how Agile methods are tightly focused on application development and architecture is assumed to be an integral part of the Agile delivery project. Yet the reality in all enterprises is that significant aspects of architecture must be consistent at the domain or enterprise level. Another good example is how the three standards bodies OASIS, OMG and the Open Group were so divergent in their treatment of SOA, they commissioned a report [ref 2 below] to explain how these inherently duplicating standards and specifications relate to each other.

The level of adoption by enterprises or service providers of all these and similar practice frameworks and standards is of course highly variable. However it must be said that the very existence of the discipline based materials will frequently have some considerable influence on how enterprises organize themselves.

The thinking IT or business professional might also like to question just how up to date these frameworks are, and how they support today’s business goals, which for most of us have changed dramatically over the past few years. We might also speculate whether the education and certification ecosystems that feed off some discipline based frameworks may discourage rapid evolution. A good example is how TOGAF maintains the core architecture style as application centric and treats SOA as a style extension. This is really quite extraordinary because by now everyone knows and many accept the digital business is going to be inherently service oriented. In practice of course the TOGAF specifications are so extensive that making fundamental changes may be very difficult, but it demonstrates neatly how legacy capabilities become “part of the furniture”, not just in frameworks but also in delivered systems and services.

Which brings me right back to the question – do we really need another practice framework? 

For several years now I and my colleagues have been evolving and implementing a different transformation approach. Initially we focused on SOA. And as many will know, we were fundamentalists in this area and we published detailed and open meta models for the service architecture and delivery life cycle based on “everything is a Service”. This approach has been very successful, particularly when the service architecture conforms with a strong layered reference architecture and rigorous componentization of services and business capabilities. But because we always knew that there was no such thing as a green field, we worked to harvest knowledge from existing systems. And over time we made a virtue of this,  focusing on continuous modernization as a matter of principle. More recently we have further evolved the approach to embrace Agile and MDD, establishing an agile service factory and generating code from rigorously defined service specifications.
But we found many of our customers struggled to implement a strategic SOA because business change was implemented project by project. And sure enough, project specific services and SOA have become ubiquitous; you might say almost a contradiction in terms. To counter this we advise that the demand management process should be complemented with demand shaping that decomposes the customer solution based demand to discover requirements for services and other sharable components and then re-aggregates the raw component demand into related projects that coordinate the delivery of business solutions and strategic services. 
But even though this approach works well at a project and technical level, we frequently encounter difficulty in persuading business stakeholders to balance short term advantage with more strategic goals. And we recognize this is because business stakeholders habitually make investment decisions on flawed criteria, because the ROI model only looks at the solution in isolation, rather than looking at the strategic opportunities to implement better architecture, address portfolio rationalization and reduce technical debt. This prompted us to find ways of working more effectively with business stakeholders. To encourage them to understand and indeed influence the conceptual business model and to understand a richer underlying business model that reflects a more comprehensive cost benefit model. And this helps to bring LoB managers into the conversation on demand shaping – balancing immediate solution requirements with longer term goals. 

In effect what we did was to establish a service and solution delivery value chain that commences with the raw customer demand and finishes with the delivery and integration of some useful business capability, but crucially with a much improved balance between immediate solution needs and longer term strategic goals. And it’s this balance that many enterprises find extremely difficult to achieve.
The core problem is that disciplines are vertically integrated; set up to optimize the discipline at varying levels of abstraction. In contrast the value chain approach optimizes across disciplines in pursuit of overall value chain outcomes. And this is only achieved by value chain activities that encourage effective collaborations between multiple capabilities and disciplines.

In the beginning we (Everware-CBDI) had a framework – Service Architecture & Engineering (SAE). The name makes it clear this is a forward engineering approach, and whilst it was very strongly business driven, it would be fair to say that the business modeling components were less well worked than the architecture, design and delivery. And as described we have very naturally, as part of the process of supporting large enterprise initiatives, expanded the framework capabilities and embraced an inherently Agile approach.

The principles underlying the framework now include:
– business capability based modularity
– pervasive service architecture
– continuous modernization
– service evolution not (one time) delivery
– model driven architecture and development
– everything is inherently agile – iterative, evolving, and narrowly focused on specific business capability delivery.

So to answer my own question, we clearly need a new framework. But it’s a very different practice framework to the ones that we are are accustomed to.
In our natural evolutionary process we recognized that the original (SAE) framework was merely one component of a much broader body of knowledge and practices. The new framework is goal driven, not discipline driven and incorporates the entire value chain of capabilities. But the capabilities are not standalone, they are effectively services that are executed in a way that supports the overall business goals of the enterprise, domain or program. We refer to this as  Service Oriented Application Modernization (SOAM).

Interestingly this is not a monolithic framework. It’s vital to treat the framework as a set of capabilities with defined services and dependencies. Some might say, “eating our own dog food”. In this way we don’t make the same mistake as legacy frameworks such as TOGAF, that are very difficult to keep current.

Finally what happens to the existing discipline based frameworks and standards? Of course they can be used in conjunction with the SOAM framework. But we do need to be careful not to just inherit monolithic capabilities. Increasingly we find it necessary to do this very selectively in order to use capabilities that fit and support the value chain. Perhaps in time the various disciplines will recognize the monolithic nature of their practices, and decompose and modernize into more goal oriented components. Meanwhile, in SOAM we have demonstrated that it is possible to reinvent the wheel.

Some SOAM Components:
    Agile Service Factory
    Agile Modernization
    Conceptual (Agile) Business Modeling
    SOA Reference Framework

Ref 1: Beware the New Silos

Oh No! We need another Practice Framework?

by

A few years ago I commented [in Beware the New Silos, ref 1 below] that in a complicated world we cope by specialization – and across the industry in general and in individual enterprises specifically we have created silos of our primary disciplines. The widely used frameworks and methods illustrate that common practice of discipline centricity. We don’t have to look too far for examples such as Enterprise Architecture (TOGAF), Governance (Cobit), SOA (separately by OASIS, OMG, Open Group), Agile methods (many and various), Business Process Management (BPM) and IT Service Management (ITIL). All of these disciplines, whether de jure or de facto standards, are all very narrowly focused with minimal treatment of how the disciplines might work together.

A good example is how Agile methods are tightly focused on application development and architecture is assumed to be an integral part of the Agile delivery project. Yet the reality in all enterprises is that significant aspects of architecture must be consistent at the domain or enterprise level. Another good example is how the three standards bodies OASIS, OMG and the Open Group were so divergent in their treatment of SOA, they commissioned a report [ref 2 below] to explain how these inherently duplicating standards and specifications relate to each other.

The level of adoption by enterprises or service providers of all these and similar practice frameworks and standards is of course highly variable. However it must be said that the very existence of the discipline based materials will frequently have some considerable influence on how enterprises organize themselves.

The thinking IT or business professional might also like to question just how up to date these frameworks are, and how they support today’s business goals, which for most of us have changed dramatically over the past few years. We might also speculate whether the education and certification ecosystems that feed off some discipline based frameworks may discourage rapid evolution. A good example is how TOGAF maintains the core architecture style as application centric and treats SOA as a style extension. This is really quite extraordinary because by now everyone knows and many accept the digital business is going to be inherently service oriented. In practice of course the TOGAF specifications are so extensive that making fundamental changes may be very difficult, but it demonstrates neatly how legacy capabilities become “part of the furniture”, not just in frameworks but also in delivered systems and services.

Which brings me right back to the question – do we really need another practice framework? 

For several years now I and my colleagues have been evolving and implementing a different transformation approach. Initially we focused on SOA. And as many will know, we were fundamentalists in this area and we published detailed and open meta models for the service architecture and delivery life cycle based on “everything is a Service”. This approach has been very successful, particularly when the service architecture conforms with a strong layered reference architecture and rigorous componentization of services and business capabilities. But because we always knew that there was no such thing as a green field, we worked to harvest knowledge from existing systems. And over time we made a virtue of this,  focusing on continuous modernization as a matter of principle. More recently we have further evolved the approach to embrace Agile and MDD, establishing an agile service factory and generating code from rigorously defined service specifications.
But we found many of our customers struggled to implement a strategic SOA because business change was implemented project by project. And sure enough, project specific services and SOA have become ubiquitous; you might say almost a contradiction in terms. To counter this we advise that the demand management process should be complemented with demand shaping that decomposes the customer solution based demand to discover requirements for services and other sharable components and then re-aggregates the raw component demand into related projects that coordinate the delivery of business solutions and strategic services. 
But even though this approach works well at a project and technical level, we frequently encounter difficulty in persuading business stakeholders to balance short term advantage with more strategic goals. And we recognize this is because business stakeholders habitually make investment decisions on flawed criteria, because the ROI model only looks at the solution in isolation, rather than looking at the strategic opportunities to implement better architecture, address portfolio rationalization and reduce technical debt. This prompted us to find ways of working more effectively with business stakeholders. To encourage them to understand and indeed influence the conceptual business model and to understand a richer underlying business model that reflects a more comprehensive cost benefit model. And this helps to bring LoB managers into the conversation on demand shaping – balancing immediate solution requirements with longer term goals. 

In effect what we did was to establish a service and solution delivery value chain that commences with the raw customer demand and finishes with the delivery and integration of some useful business capability, but crucially with a much improved balance between immediate solution needs and longer term strategic goals. And it’s this balance that many enterprises find extremely difficult to achieve.
The core problem is that disciplines are vertically integrated; set up to optimize the discipline at varying levels of abstraction. In contrast the value chain approach optimizes across disciplines in pursuit of overall value chain outcomes. And this is only achieved by value chain activities that encourage effective collaborations between multiple capabilities and disciplines.

In the beginning we (Everware-CBDI) had a framework – Service Architecture & Engineering (SAE). The name makes it clear this is a forward engineering approach, and whilst it was very strongly business driven, it would be fair to say that the business modeling components were less well worked than the architecture, design and delivery. And as described we have very naturally, as part of the process of supporting large enterprise initiatives, expanded the framework capabilities and embraced an inherently Agile approach.

The principles underlying the framework now include:
– business capability based modularity
– pervasive service architecture
– continuous modernization
– service evolution not (one time) delivery
– model driven architecture and development
– everything is inherently agile – iterative, evolving, and narrowly focused on specific business capability delivery.

So to answer my own question, we clearly need a new framework. But it’s a very different practice framework to the ones that we are are accustomed to.
In our natural evolutionary process we recognized that the original (SAE) framework was merely one component of a much broader body of knowledge and practices. The new framework is goal driven, not discipline driven and incorporates the entire value chain of capabilities. But the capabilities are not standalone, they are effectively services that are executed in a way that supports the overall business goals of the enterprise, domain or program. We refer to this as  Service Oriented Application Modernization (SOAM).

Interestingly this is not a monolithic framework. It’s vital to treat the framework as a set of capabilities with defined services and dependencies. Some might say, “eating our own dog food”. In this way we don’t make the same mistake as legacy frameworks such as TOGAF, that are very difficult to keep current.

Finally what happens to the existing discipline based frameworks and standards? Of course they can be used in conjunction with the SOAM framework. But we do need to be careful not to just inherit monolithic capabilities. Increasingly we find it necessary to do this very selectively in order to use capabilities that fit and support the value chain. Perhaps in time the various disciplines will recognize the monolithic nature of their practices, and decompose and modernize into more goal oriented components. Meanwhile, in SOAM we have demonstrated that it is possible to reinvent the wheel.

Some SOAM Components:
    Agile Service Factory
    Agile Modernization
    Conceptual (Agile) Business Modeling
    SOA Reference Framework

Ref 1: Beware the New Silos

Public Sector Open Data via Information Sharing and Enterprise Architecture

by

The title of this article is quite a mouthful, and three very complex and broadly-scoped disciplines mashed together. But that’s what’s happening all over, isn’t it, driven by consumer demand on their iPhones – mashing and manipulating information that’s managed to leak through the risk-adverse, highly-regulated mantle of the government’s secure data cocoon, and instantly sharing it for further rendering, visualization or actual, productive use. Mostly a “pull” style information flow, at best constrained or abstracted by public sector EA methods and models – at worst, simply denied.

This demand for open data, however, is rapidly exposing both opportunities and challenges within government information-sharing environments, behind the firewall – in turn a fantastic opportunity and challenge for the Enterprise Architects and Data Management organizations.

The recent “Open Data Policy” compels US Federal agencies to make as much non-sensitive, government-generated data as possible available to the public, via open standards in data structures (for humans and machine-readable), APIs (application programming interfaces) and browser-accessible functions. The public (including commercial entities) in turn can use this data to create new information packages and applications for all kinds of interesting and sometimes critical uses – from monitoring the health of public parks to predicting the arrival of city buses, or failure of city lights.

But there isn’t an “easy” button. And, given the highly-regulated and tremendously complex nature of integrated, older government systems and their maintenance contracts – significant internal change is very difficult, to meet what amounts to a “suggested” and unfunded (but with long-term ROI) mandate, without much in the way of clear and measurable value objectives.

That doesn’t mean there aren’t whole bunches of citizens and government employees ready, willing and enthusiastic about sharing information and ideas that clearly deliver tangible, touchable public benefit. Witness the recent “Open Data Day DC“, a yearly hackathon in the District of Columbia for collaborating on using open data to solve local DC issues, world poverty, and other open government challenges. Simply sharing information in ways that weren’t part of the original systems integration requirements or objectives has become a very popular – and in fact expected behavior – of the more progressive and (by necessity) collaborative agencies – such as the Department of Homeland Security (DHS).  

The Information Sharing Environment is the nation’s most prominent and perhaps active federal information sharing model – though its mission really generates “open data” products for a closed community (vs. the anonymous public) – i.e. those that deal with sensitive national security challenges. For information sharing purposes, however, it’s a very successful and well-documented, replicable model for any context that includes multiple government entities and stakeholders (whether one agency or department, or a whole city or state). A pragmatic Information Sharing Environment – with enthusiastic, knowledgeable and authoritative champions – is also the first, most important leg of the stool that supports successful Open Data initiatives.

The second leg is Enterprise Architecture – thinking of “open data” as the “demand” side of the equation, and “information sharing” as the conduit and source of “authorities” (i.e. policies, rules, governance, roles; internal and external) – EA can represent the “supply”. “Represent” the supply, not “be” the supply; the “supply” are the actual agency assets, including data, budget, contracts, personnel, etc. EA can inform regarding what data is available where and when, with what constraints, in what format or representations, via which IT interfaces, and via which business or technology resources. What can or needs to be changed, or what will be impacted, for the supply to meet the demand? Perhaps reusable IT exists that can be fully leveraged to meet the requirements, perhaps existing Oracle SOA, BPM and WebCenter assets?

The third leg of course is the inventory of data assets available – data assets include not only the raw data, but the metadata and registries, data access functions and APIs, data models and schemas, and the information technologies and systems that produce, manipulate, manage, protect and store the data. Plus really neat, useful commercial and open source open data tools to help. Whether they exist already, or need to be created.

So it conceptually works as follows, very abstractly-mirroring the well-known “People, Process, Technology” business model;

  1. People – An information-sharing environment and culture develops, enabling productive dialogue and guidance about proactively or reactively creating “open data” from enterprise assets to share with the public;
  2. Process – An Enterprise Architecture method and framework is leveraged, to define and scope the “art of the possible” in leveraging enterprise data assets, in terms that enable compliant program and engineering planning; and
  3. Information Technology – Useful, standards-based data products are cataloged and exposed to the public (better with some initial protoyping), meeting requirements and expectations, appropriately constrained by law, policy, regulations and investment controls. 

 Significant open data, and open government initiatives can’t succeed and persist without all three perspectives, all three domains of organizational expertise.

Platform for Housing part 2: a bit more detail #ukhousing

by

A couple of weeks ago I wrote this post trying to pin down some ideas about a different approach that the housing community might take to supporting service delivery through information systems.

It was a bit out there and not fully formed, but seemed to get a good response and sparked some debate. The intention of this post is to try and layer on some more detail from the previous post (although it’ll still be pretty abstract)

Looking at a service and capability viewpoint most housing associations look like this

image

There will be exceptions and additions, some will include care and support services, some telecare, some even leisure centre management (!?) but at the housing core they all look pretty similar.

(NB this isn’t an organisational/structural view, this is about services)

Due to the history of where housing associations originated from (through mergers and transfers), the age of some of them and the source of growth for some of the larger ones, many also look like this from an information systems perspective:

image

With lots of duplicate information systems delivering the the same or similar capabilities.

E.g. the RP that brought over its Local authority legacy, The RP that fought for a semblance of independence when it got subsumed, The integration project that didn’t integrate everything.

So for many housing associations one of the aims (some may have achieved it, some may be on the journey, some may be unaware of the need for the journey but are no doubt feeling seeing the symptoms of the status quo) is this

image

Rationalisation.

Those that are already on the rationalisation route may also  be doing some consolidation of capabilities through abstraction. what does that mean?

e.g. lets not silo identity for each app, lets do it once.

e.g. Lets manage documents one way rather than 10

e.g. if we are going to manage a customer case lets do it once for the organisation

e.g. scheduling person, with skills, in a location, at a time, lets do that once for the organisation

Others, thinking themselves advanced beyond these sort of considerations might be heading towards what i’d like to term ‘homogenised housing’. Dropping a big box on lots of the common capabilities of business execution

You might call this ERP and it might look like this

image

Where generic business capabilities that are common to business execution are ‘solved’ by the ERP box and the ‘specialised’ elements outside of the box are much reduced.

So currently we are in this world

imageWhere lots of similar organisations, doing similar things are individually spending time, effort and money attempting to solve the common problems of the industry.

How is this maximising the value that individual housing associations delivers to its customers?

How is this maximising the value that the #ukhousing community delivers to its customers and society?

Whilst writing my previous post I had something like this in my head

image

A shared platform of for housing services, shared by the community, built for the communities customers needs, led by the community, funded by the community

This would enable organisations to:

  • Acquire capabilities at a lower cost
  • Integrate with whatever stuff they want to keep control of
  • Multiply the value of the insight they can get from their data by pooling
  • Disrupt a turgid marketplace for the good of the community

Next

Assuming that what I’ve described above a) makes sense and b) is a good idea, what then do we need to do to get started?

First, i think we need to think about Ego and Altruism.

Lets remove the ego that lets us pretend that the services we deliver to our customers are unique.

Lets remove the ego that drives us to feel good about solving problems for ‘our customers’.

Lets think about altruism and the benefits of pooling our resources for all ‘our customers’. Lets think about how larger organisations with the capacity to sponsor such an endeavour might aid smaller ones.

Second/3rd/4th/5th/etc, there are loads of questions e.g.:

What would the first services of the platform be?

What would the platform technology be?

Would it be open source?

Would it be offered as Software as a Service?

What is the business model?

Who would sponsor it?

How would this be organised?

But before we answer those questions I guess the vision and principles need to be validated. So, community, what do we think?

Categories Uncategorized

Link: The Nine Elements of Digital Transformation | MIT Sloan Management Review

by

Another perspective, similar findings:

“Companies in all industries and regions are experimenting with — and benefiting from — digital transformation. Whether it is in the way individuals work and collaborate, the way business processes are executed within and across organizational boundaries, or in the way a company understands and serves customers, digital technology provides a wealth of opportunity.”

MIT Center for Digital Business research surfaced 9 elements across three categories:

Transforming Customer Experience

  • Customer Understanding
  • Top-Line Growth
  • Customer Touch Points

Transforming Operational Processes

  • Process Digitization
  • Worker Enablement
  • Performance Management

Transforming Business Models

  • Digitally Modified Businesses
  • New Digital Businesses
  • Digital Globalization

For the details:  The Nine Elements of Digital Transformation | MIT Sloan Management Review.

Service Factory 2.0

by

In July 1989 the Harvard Business Review published a seminal article by Chase and Garvin titled The Service Factory [1]. They argued that “The factory of the future is not a place where computers, robots, and flexible machines do the drudge work. . . the next generation, then, will compete by bundling services with products, anticipating and responding to a truly comprehensive range of customer needs.”

Since the publication some 25 years ago, much has happened to validate Messrs Chase and Garvin’s thesis. The world has manifestly transformed into a “service based world”. By some accounts the service sector grew to over 80% of the US economy by 2000. There are various implementations of the Service Factory concept; we might observe that the ubiquitous Call Centers represent a scalable, repeatable factory model. Similarly in the technology world services, or APIs, are a central part of many IT architectures, and some firms have adopted a service factory model by separating service and solution delivery.

But it must be said that for most enterprises there remains a significant gap between the business and software services. Over 25 years ago Chase and Garvin recognized this as an issue. They use the example of how 200 years ago horse-drawn carriages were mostly made by craftsmen, and the most successful carriage maker was invariably the most accommodating for the customer. But as mass production overtook craftsmanship customers came to value standardized, lower price more than higher price, personalized products. Gradually manufacturing became separated from pre and post-sale customer facing activities. In recent years in some industry sectors, there has been a noticeable reversal of this trend, and mass customization is widely practiced. However in many industries, notwithstanding Agile methods focus on customer involvement, the design of business services remains a discrete activity from the architecture and design of IT services.

This is starting to change. The Mobile revolution and the Internet of Things will inevitably cause a convergence of business and software services. I have described this as “turning the business inside out”. In future it will be a very rare business service that isn’t delivered by a software service, at least as an option or complement. It’s a racing certainty that Call Centers and other conventional service delivery models are going to go the same way as Telephone Exchanges, Typing Pools and Airline Reservations Departments! In this fast emerging world, “everything is a service”. And this will have a profound impact on the shape of the Service Factory of tomorrow.

The Service Factory 2.0 will be a software factory separate from solution delivery projects. As discussed some firms already employ this organizing model in order to architect and design services to standardize core business information and rules for use in many processes.

The software factory concept has been in use for some time, particularly in conjunction with the Product Line concept, where common components are delivered using a framework of tools, repeatable processes and patterns, that are reused in solutions supporting the Product Line. The Service Factory 2.0 is a specialization of the software factory, with a framework that is specific to services. However the most effective service factory will also be a “business service” delivery model in which the life cycle of the business, software and IT service perspectives are integrated.

We can anticipate a number of critical innovations that will enable the Service Factory 2.0:

1. Everything is a Service All business capabilities are delivered as modular software services which are integral to the holistic business service offering.
2. Automated Requirements Capture. The requirements activity is automated in a manner that facilitates the involvement of the real stakeholders in the specification of the business, software and IT service, in a language that is entirely natural to them and to engage meaningfully in distributed Agile processes.
3. Automation of Common Service Patterns. The Service Factory frameworks that bootstrap service implementations will increasingly automate many of the common architectural and business model styles. Yet unlike the de facto application package products, the Service Factory will facilitate the extension and customization of the common pattern to allow competitive differentiation for the customer organization, as well as ongoing flexibility.
4. Service Portfolio Management. The Service Factory must support the management of the “business service” and provide tools that integrate demand management, architecture and governance over a composable and constantly evolving business and software service portfolio.
6. Pattern R&D. An important role of the service factory will be to continuously evolve patterns to enable and support innovation in styles of business service together with increased scope of automation coverage
7. Architecture Managed Iteration. Pattern based development delivers code that is always compliant with the architecture, but also with meta data that allows full automation of configuration management. This facilitates continuous, low effort iteration in the delivery, test, DevOps cycle and evolution in production.

In their paper, Chase and Garvin quote Drucker who noted that the imperatives of information-based competition are breaking down barriers within businesses and making functional divisions obsolete. To my mind, the primary characteristic of Service Factory 2.0 will be the realization of the business, software and IT service as a composite offering, architected, designed and delivered as a business asset.

[1]  The Service Factory, Chase, Garvin, HBR

Link: Everware-CBDI Service Factory as a Servicehttp://agileservicefactory.com

Service Factory 2.0

by

In July 1989 the Harvard Business Review published a seminal article by Chase and Garvin titled The Service Factory [1]. They argued that “The factory of the future is not a place where computers, robots, and flexible machines do the drudge work. . . the next generation, then, will compete by bundling services with products, anticipating and responding to a truly comprehensive range of customer needs.”

Since the publication some 25 years ago, much has happened to validate Messrs Chase and Garvin’s thesis. The world has manifestly transformed into a “service based world”. By some accounts the service sector grew to over 80% of the US economy by 2000. There are various implementations of the Service Factory concept; we might observe that the ubiquitous Call Centers represent a scalable, repeatable factory model. Similarly in the technology world services, or APIs, are a central part of many IT architectures, and some firms have adopted a service factory model by separating service and solution delivery.

But it must be said that for most enterprises there remains a significant gap between the business and software services. Over 25 years ago Chase and Garvin recognized this as an issue. They use the example of how 200 years ago horse-drawn carriages were mostly made by craftsmen, and the most successful carriage maker was invariably the most accommodating for the customer. But as mass production overtook craftsmanship customers came to value standardized, lower price more than higher price, personalized products. Gradually manufacturing became separated from pre and post-sale customer facing activities. In recent years in some industry sectors, there has been a noticeable reversal of this trend, and mass customization is widely practiced. However in many industries, notwithstanding Agile methods focus on customer involvement, the design of business services remains a discrete activity from the architecture and design of IT services.

This is starting to change. The Mobile revolution and the Internet of Things will inevitably cause a convergence of business and software services. I have described this as “turning the business inside out”. In future it will be a very rare business service that isn’t delivered by a software service, at least as an option or complement. It’s a racing certainty that Call Centers and other conventional service delivery models are going to go the same way as Telephone Exchanges, Typing Pools and Airline Reservations Departments! In this fast emerging world, “everything is a service”. And this will have a profound impact on the shape of the Service Factory of tomorrow.

The Service Factory 2.0 will be a software factory separate from solution delivery projects. As discussed some firms already employ this organizing model in order to architect and design services to standardize core business information and rules for use in many processes.

The software factory concept has been in use for some time, particularly in conjunction with the Product Line concept, where common components are delivered using a framework of tools, repeatable processes and patterns, that are reused in solutions supporting the Product Line. The Service Factory 2.0 is a specialization of the software factory, with a framework that is specific to services. However the most effective service factory will also be a “business service” delivery model in which the life cycle of the business, software and IT service perspectives are integrated.

We can anticipate a number of critical innovations that will enable the Service Factory 2.0:

1. Everything is a Service All business capabilities are delivered as modular software services which are integral to the holistic business service offering.
2. Automated Requirements Capture. The requirements activity is automated in a manner that facilitates the involvement of the real stakeholders in the specification of the business, software and IT service, in a language that is entirely natural to them and to engage meaningfully in distributed Agile processes.
3. Automation of Common Service Patterns. The Service Factory frameworks that bootstrap service implementations will increasingly automate many of the common architectural and business model styles. Yet unlike the de facto application package products, the Service Factory will facilitate the extension and customization of the common pattern to allow competitive differentiation for the customer organization, as well as ongoing flexibility.
4. Service Portfolio Management. The Service Factory must support the management of the “business service” and provide tools that integrate demand management, architecture and governance over a composable and constantly evolving business and software service portfolio.
6. Pattern R&D. An important role of the service factory will be to continuously evolve patterns to enable and support innovation in styles of business service together with increased scope of automation coverage
7. Architecture Managed Iteration. Pattern based development delivers code that is always compliant with the architecture, but also with meta data that allows full automation of configuration management. This facilitates continuous, low effort iteration in the delivery, test, DevOps cycle and evolution in production.

In their paper, Chase and Garvin quote Drucker who noted that the imperatives of information-based competition are breaking down barriers within businesses and making functional divisions obsolete. To my mind, the primary characteristic of Service Factory 2.0 will be the realization of the business, software and IT service as a composite offering, architected, designed and delivered as a business asset.

[1]  The Service Factory, Chase, Garvin, HBR

Link: Everware-CBDI Service Factory as a Service

Agile SOA in the Digital Economy

by

Are you and your enterprise a prisoner of the past? I don’t mean legacy applications and technologies, I mean today’s business processes and applications. I work with many different enterprises and what’s common to the great majority is the centrality of business processes and applications, and the difficulty in evolving these existing solutions.

Actually I am frequently amazed at the understanding of many business managers. I marvel at how they use the lingua franca of their applications to describe their business. I will readily admit that when I first meet someone like this it’s a bit scary, because their vocabulary is like a foreign language. But frequently I find that it’s also a foreign language to their colleagues and it represents a rather primitive form of power play! Believe me. And that vocabulary of course often pervades the business process also. But the even scarier thing is that these organizations don’t realize they are locked into yesterday; or looking in the rear view mirror is you prefer. And just like Fred Brooks mythical beasts, struggling against the grip of the tar pits [1], they will eventually be overwhelmed by the complexity and their inability to change. Yes they may be delivering Cloud based Web and mobile applications to their customers, but are they just adding to the inherent business complexity?

I observe smart, successful companies making major mistakes as they enter the digital economy. First they set up an eServices project or division. This is treated as an innovation center and separated from the core business, in order to get to market quickly. But of course when they get to market the new products don’t integrate with the core business. Sure there’s application and service integration, anyone can patch old and new together at that level; but what about the way the business works; the business model and the vocabulary used, the opportunities for channel switching, and the development of distinctive sales and customer support systems and internal and external company culture that transcends the technology channels. And the ability to evolve the old and new in a way that they complement each other?

This problem is visible in the decreasing agility of organizations. Many have adopted Agile development but, and I say this as a certified Scrum Master, how many Agile projects think about the vocabulary and integrated business model issue? Yes Agile projects generally deliver faster, better and cheaper, but are they basically adding to the size and eventual grip of the tar pit? Just getting there faster!

In the digital economy enterprises must turn themselves inside-out! Expose their core business capabilities as services through multiple, interconnected channels for internal and external use. Today’s SOA best practice is primarily inwards looking. What’s required is a new form of business model that details the new world from the customers’ perspective. And this needs to be reflected in the way the business operates internally also.

The new business model needs to be a radical departure from de facto practices in business architecture, enterprise architecture or business requirements. And it needs to be developed to govern Agile development projects. Key characteristics include:
– A service oriented business model that transcends business and IT.
– Understandable by all stakeholders
– Owned by the business.
– All enterprise capabilities are (eventually) published as externalized business services and supported by common software services
– Implementation independent models
– Developed as part of an Agile process – initial scoping sprint, followed by drill down modeling sprints by domain and or capability; delivering just sufficient detail to charter Agile delivery projects.

[1] The Mythical Man-Month, Fred Brooks, 1972

Agile SOA in the Digital Economy

by

Are you and your enterprise a prisoner of the past? I don’t mean legacy applications and technologies, I mean today’s business processes and applications. I work with many different enterprises and what’s common to the great majority is the centrality of business processes and applications, and the difficulty in evolving these existing solutions.

Actually I am frequently amazed at the understanding of many business managers. I marvel at how they use the lingua franca of their applications to describe their business. I will readily admit that when I first meet someone like this it’s a bit scary, because their vocabulary is like a foreign language. But frequently I find that it’s also a foreign language to their colleagues and it represents a rather primitive form of power play! Believe me. And that vocabulary of course often pervades the business process also. But the even scarier thing is that these organizations don’t realize they are locked into yesterday; or looking in the rear view mirror is you prefer. And just like Fred Brooks mythical beasts, struggling against the grip of the tar pits [1], they will eventually be overwhelmed by the complexity and their inability to change. Yes they may be delivering Cloud based Web and mobile applications to their customers, but are they just adding to the inherent business complexity?

I observe smart, successful companies making major mistakes as they enter the digital economy. First they set up an eServices project or division. This is treated as an innovation center and separated from the core business, in order to get to market quickly. But of course when they get to market the new products don’t integrate with the core business. Sure there’s application and service integration, anyone can patch old and new together at that level; but what about the way the business works; the business model and the vocabulary used, the opportunities for channel switching, and the development of distinctive sales and customer support systems and internal and external company culture that transcends the technology channels. And the ability to evolve the old and new in a way that they complement each other?

This problem is visible in the decreasing agility of organizations. Many have adopted Agile development but, and I say this as a certified Scrum Master, how many Agile projects think about the vocabulary and integrated business model issue? Yes Agile projects generally deliver faster, better and cheaper, but are they basically adding to the size and eventual grip of the tar pit? Just getting there faster!

In the digital economy enterprises must turn themselves inside-out! Expose their core business capabilities as services through multiple, interconnected channels for internal and external use. Today’s SOA best practice is primarily inwards looking. What’s required is a new form of business model that details the new world from the customers’ perspective. And this needs to be reflected in the way the business operates internally also.

The new business model needs to be a radical departure from de facto practices in business architecture, enterprise architecture or business requirements. And it needs to be developed to govern Agile development projects. Key characteristics include:
– A service oriented business model that transcends business and IT.
– Understandable by all stakeholders
– Owned by the business.
– All enterprise capabilities are (eventually) published as externalized business services and supported by common software services
– Implementation independent models
– Developed as part of an Agile process – initial scoping sprint, followed by drill down modeling sprints by domain and or capability; delivering just sufficient detail to charter Agile delivery projects.

[1] The Mythical Man-Month, Fred Brooks, 1972

Enterprise Architecture as Science?

by

It is common to describe Enterprise Architecture as a science. Here are a few examples.

  • We see enterprise architecture (EA) as a scientific sub-discipline both of computer science and business management. The twice mentioned word “science” here emphasizes our certainty that EA is an exact discipline able to produce precise approaches and solutions. Wolf Rivkin, Enterprise Architecture and the Elegant Enterprise (Architecture and Governance 5-3)

A few years ago, I discussed this question with @RSessions

Roger is one of the few people I know who is seriously committed to empirical investigation of EA. I believe he shares my view that much EA falls woefully short of anything like scientific method. To my eye, many knowledge-claims within the EA world look more like religion or mediaeval scholastic philosophy than empirically verifiable science.

But why does it matter anyway? Why would people be so keen to claim EA as a science? Here is what Foucault had to say to those who wished to claim Marxism (or psychoanalysis) as a science.

“When I see you trying to prove that Marxism is a science, to tell the truth, I do not really see you trying to demonstrate once and for all that Marxism has a rational structure and that its propositions are therefore the products of verification procedures. I see you, first and foremost, doing something different. I see you connecting the Marxist discourse, and I see you assigning to those who speak that discourse the power-effects that the West has, ever since the Middle Ages, ascribed to a science and reserved for those who speak a scientific discourse.” Michel Foucault, Society Must be Defended: Lectures at the Collège de France, 1975-76 (English translation by David Macey, 2003)

In other words, claiming EA as a science is not about the rational basis for its knowledge-claims but about its authority, or what Foucault (in David Macey’s translation) calls Power-Effects. Thus instead of claiming EA as a science, one might follow Gartner in claiming EA as a discipline.


Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions. EA is used to steer decision making toward the evolution of the future state architecture. (Gartner website, retrieved 17 August 2013)

Foucault characterizes a discipline in terms of the selection, normalization, hierarchicalization and centralization of knowledge. We can surely recognize these processes in the formation and maintenance of EA frameworks such as TOGAF and PEAF, as well as various attempts to construct Bodies of Knowledge. Foucault notes that “the progress of reason” necessitates “the disciplinarization of polymorphous and heterogeneous knowledge”. This might lead us to expect some institutional resistance to heterodox ideas, as well as the marginalization of “amateur scholars”.

Foucault is interested in ways that people and organizations can respond to disruptive forces large and small, from “great radical ruptures, massive binary divisions” to “mobile and transitory points of resistance, producing cleavages in a society that shift about, fracturing unities and effecting regroupings”.

Just as the network of power relations ends by forming a dense web that passes through apparatuses and institutions, without being exactly localized in them, so too the swarm of points of resistance traverses social stratifications and individual unities. And it is doubtless the strategic codification of these points of resistance that makes a revolution possible. [Michel Foucault, History of Sexuality Vol 1.]

Gartner’s notion of EA-as-discipline seems quite consistent with this. It is focused on mobilizing the response to disruptive forces (for which Gartner uses the rather strange word “nexus”). EA gains its power from a kind of strategic codification (or discursive practice), allowing the enterprise to “harness the nexus”, thereby “revolutionizing business and society, disrupting old business models and creating new leaders”. (Gartner website, retrieved 17 August 2013)

Update

@tetradian commented on the dangers of spurious ‘authority’ – ‘spurious’ in sense of claiming an aura of ‘authority’ when there’s none to be had (b/c it isn’t ‘science’ anyway)

I agree that claims of scientific status or method in the EA world are generally spurious. But there are other ways of asserting authority. For me, the key question is why (and on what grounds) should anyone trust the pronouncements of EA. It is not just about danger versus safety, but about authority versus authenticity.