Search Results for “business model” – Page 54

Enterprise Architecture: It’s Not Just About Technology Anymore

July 17, 2014 by Troux Staff

bg outline

Ben Geller, VP Marketing, Troux

renaissance opt1 071614 2 (2) In our last blog post, The Next Chapter of Enterprise Architecture: Self-Service, we examined the change in mind-set that seems to be occurring in all corners of the enterprise when it comes to EA. We wrote about EA tools as a catalyst to empower stakeholders all across the enterprise with quality decision-making information available whenever needed:

“With digital and technological disruptors firmly rooted in our world there is a massive mind shift at play in how we interact with technology as well as how we expect to get things done.”

In this post we will further explore why the timing now seems right for EA to go through this renaissance.

To start, EA has evolved. It is no longer an IT-centric discipline focused on creating a set of artifacts in the form of complex maps and models only understood by a few with limited ‘actionability’ in terms of driving measurable business outcomes. To serve the evolving needs of decision-makers EA has evolved as well. With the rise of digital business and the rapid pace of change in the market it is more important than ever for decision-makers to not only know exactly where to invest in their business, but to also better understand the impacts of those investment decisions.

“While many biz & IT execs are aware of disruptive innovations in IT (such as the nexus of forces and digital business), they often struggle to identify the impact and implications of these innovations to their business model.” – Gartner

With the most comprehensive understanding of how every piece of an organization is connected, enterprise architects are poised to take the lead in how the enterprise responds to disruptive forces and change, whatever their origin.

When we talk about disruptive forces we mean consumer expectations, digital business, new technologies, regulatory demands, social media and more. EA in a leadership role helps organizations navigates these disruptors while staying focused on its strategic goals and vision.

In this new era enterprise architects still have to maintain their knowledge of IT, but they have to move beyond those contributions and activities, introducing themselves as strategic advisors who communicate EA’s value to all parts of the business. Today, enterprise architects are also looked to for strategic budget decisions. They must be able to vet how a new investment will support corporate outcomes and transform the business. Further, they must assimilate the integration costs and process to assure the company realizes the value.

This renaissance of EA has only just begun, but some big wins are already in the marketplace. Read how Troux customer HSBC is undertaking a massive program to simplify operations through EA. Find the complete article on Computer Weekly, HSBC makes executives responsible for application consolidation.

Being Forgotten in the Internet of Things

June 30, 2014 by Nick Malik

We all know that Google lost a landmark legal case recently. As of now, a citizen of Europe has the “right to be forgotten” on the Internet. As of now, a citizen of Europe can ask Google to “forget” them, so that a search of their identity will not return embarrassing information from the past. This allows a person to live past a mistake. Your college indiscretion, and that time you were fired for photocopying your butt, or the time you got drunk and drove your car into a swamp and had to be rescued… all of that can “go away.”

However, this becomes much more difficult when we consider the emerging Internet of Things (IoT). In the Internet of Things, the “stuff” that you own can generate streams of data that do not remain within your control. That data is called “Information Property.” It is the information that YOU generate, in the things that you do. I believe that if YOU create a bit of information property, you should own it.

That information property, thousands of tiny bits of data about you or your activities, will wander out of your house, or your car, or your phone, to companies and governments running cloud-based data centers. That swarm of data surrounds you, and be used to profile you, track you, predict your actions, influence your choices, and limit your abilities to get “outside” the system. Most folks will not have any problem with this cloud of data. At least not at first.

Where we will first feel the pain of this cloud of data: when you want to be forgotten.

A parallel that does work

We have been dealing with “data about you” for a while. When you apply for a loan or a credit card, the information you submit becomes the property of your creditor, and they share that data with credit reporting agencies, along with your payment history, employment history, residential history, status of property ownership, and basically any other factor that finance companies feel would influence your likelihood to pay your debts. The US Federal Government has placed some controls on this data, but not many. Europe has placed entirely different controls. You have no right to be forgotten, but you do have the right to limit their memory to a decade. That allows you to “get past” a mistake or series of mistakes. But you are always “known.” However, a mistake can be forgotten.

This is a model we can use. Here is data, about you, outside your control, that get’s “forgotten” on a regular basis as it gets old. There is a possibility in the credit reporting world for being “forgotten” because the data is tied to you, personally. It is ALL personal data.

This is not (yet) true in the Internet of Things. If your car sends data to a smart roadway system, there is a great deal of information about where you go, and when, but under most circumstances, your identity is not tied to that data. It’s the identity of the CAR that is sent, but not the identity of the driver or passenger. That can be seen as an advantage, because it is tough to link that data to you, but it is possible, and therefore it will occur. You will be found. And when it does occur, you no longer have any easy mechanism to PROVE that the data from your car relates to you. This means that if any government creates a policy to allow you to be forgotten, the car data will not go away. You can’t CLAIM that data because it is not directly linked to you. You don’t own it.

Think this is a minor problem? After all, your city doesn’t have a smart roadway yet, and your car doesn’t send data, so this problem is a long way off, right? Wrong. If we don’t think of this now, privacy will be sacrificed, possibly for decades.

The environment of regulations sets the platform by which companies create their business models. If we create a world where you cannot claim your data, and you cannot manage your data, other people will start claiming your data, and making money. Once that happens, new regulations amount to government “taking money” from a company. The typical government response is to “grandfather” existing practices (or to protect them outright). No chance to change beyond a snail’s pace at that time.

A proposal

I propose a simple mechanism. Every time you purchase a device on the IoT, you insert an ID into the device. This ID is a globally unique ID (my tech friends call this a GUID) which is essentially a very large random number. You can pick up as many as you want over your lifetime, but I’d suggest getting a new one every month. A simple app can create the GUID and manage them. Every item you purchase during that month gets the ID for that month.

Every bit of data (or Information property) sent by the device to the swarm of companies that will collect and work with this data will get your GUID.

Note that your GUID allows those companies to link your data across devices (your phone, your car, your refrigerator, your ATM card, your medical record, etc). Is this allowed? Perhaps one government or another will say “no” but that control will be easily worked around, so let’s assume that you cannot control this. The thing I want to point out is that this kind of linkage is POSSIBLE now, it’s just more difficult. But difficulty is being overcome at a huge rate with the number of computing devices growing geometrically. Let’s assume that folks can do this NOW and that you will NEVER be able to control it.

Therefore inserting an ID is not giving up control. You don’t have it now.

But it is possible, with the ID, to TAKE control. You will be able to submit a request to a regulated data management company (a category that doesn’t yet exist, but it is possible), then those systems can identify all the data records with your ID, and delete them. Only if you can claim your data can you delete it. By inserting a GUID into your Internet-of-things, you have gained a right… the right to claim your data, and therefore delete it.

It will no longer be a choice of sending a single message to a single search firm like Google. The request to delete will have to go to a broker that will distribute the request, over time, to a swarm of data management companies, to remove data tagged with these IDs.

Some implications

Now, before anyone complains that a company, once they have data, will never let it go, I would submit that is nonsense. 90% of the value of information comes from samples of that data of less than 2% of the population. In fact, the vast majority of data will be useless, and plenty of companies will be looking for excuses to toss data into the virtual trash bin. If a customer asks to delete data, it costs a micro-cent to do it, but that data is probably clogging things up anyway.

Getting a company to spend the money will probably require regulations from large players like the EU, the USA, China, Japan, Brazil, and India.

The time to act is now

Now is the time to ask for these regulations, as the Internet of Things is just getting started. Companies that understand the ability to create and manage these IDs, and respond to the request to delete information, will have a leg up on their competition. Customers will trust these companies more, and the data will be more accurate for consumers of these data services.

You cannot delete “information property” until you can claim it. The ID is the claim.

Not Another Framework? Part 2

May 8, 2014 by David Sprott

In my last post Oh No! We need another Practice Framework, I developed the earlier theme commenced in “Beware the New Silos”. I argued that the widely used frameworks are narrowly discipline centric and actually inhibit cross discipline working. I described how my own firm’s experiences have led to the development of a de facto framework, (we call it SOAM) and illustrated how this is essentially a value chain commencing with customer demand and finishing with value add to some enterprise.

I ended by sketching some basic principles concluding that we need a new framework that is goal driven and incorporates the entire value chain of capabilities, which of course may selectively reuse some parts of existing frameworks. In this post, I suggest a strawman that covers a) principles and b) capability model.

Before diving into principles, it will be useful to declare some scope. Our framework has developed from working with larger enterprises, both commercial and government in the area of business service and solution delivery. All of these enterprises share common issues that they have extensive legacy application assets that act as a serious inhibitor to business change, and successive, narrowly scoped solution projects over many years have often resulted in great complexity and technical debt. It is also common in my experience that enterprise architecture functions are routinely bypassed or ignored; that Agile methods have been attempted and found useful on narrow focused projects, but because of the constrained focus, tend to increase overall complexity of the ongoing application asset base; that consistent customer experiences are commonly compromised by narrow focused projects; and line of business managers in large enterprises are frequently dissatisfied with IT application service support.

The objectives of the framework are to:

– describe practices relevant to service and solution delivery in the digital business environment
– achieve a balance between short term goals and longer term objectives
– support progressive transformation to an enterprise comprised of independent business capabilities
– facilitate continuous, short cycle time evolution of business capability
– progressively and continuously resolve legacy portfolio complexities
– enable rapid delivery at low cost without compromise in quality

Principles are foundational for any framework.

Principles should be enduring and lead to both excellent policy communication and policy interpretation in everyday situations. I also find it useful to classify principles by subject.

Capability Model

In business architecture the capability model has become ubiquitous. And in thinking organizations I observe delivery of highly independent service and solution components that reduce dependencies and the impact of change, as well as mirroring the IT architecture on the business organization. Why wouldn’t we use the same approach in defining a set of activities to deliver services and solutions?

If you are uncertain about the capability concept, it’s important to appreciate that the optimum business capability is one that enables:
– maximum cohesion of internal functional capability, plus consistency of life cycle, strategic class (core, context, innovating . . . ), business partition (global, local, LoB . . ), standardization, customizability, stability, metrics and drivers
– defined, stable dependencies that are implemented as services
[Further reading on capability optimization ]

In the capability dependency model below, the arrows are dependencies. For example, Demand Shaping is dependent upon Conceptual Business Modeling and Portfolio Management. So this is not a flow diagram, rather all the capabilities should be regarded as iterative, I will come back and discuss how Lean principles operate in a framework like this, and as discussed above, highly independent.

Most of the capabilities in the model are self-explanatory. However some need explanation:

1. The Conceptual Business Modeling capability is the ability for business stakeholders to describe business improvement in conceptual terms. Many business people speak in solution terms. Most business requirements therefore surface as solutions, some more baked than others. Because the business stakeholder generally has the budget, the solution vision frequently drives and shapes the project with outcomes that frequently compromise the existing and planned portfolio. By educating business stakeholders to communicate in concepts, the opportunity is created to develop the business improvement idea without preconceptions of implementation or product, and to optimize architectural and portfolio integration.

2. Demand Management is reasonably well understood. Demand Shaping is best regarded as a complementary capability that takes raw customer demand and decomposes into components such as pre-existing or planned services/APIs, considers opportunities for modernization and provisioning, and reassembles as a set of projects or project components that optimize the progressive development of the portfolio. Demand Shaping is primarily an architectural task, but should be run by a cross functional team including architect, product management, business design and technical expert roles.

3. The Architecture Capability is shown as a decomposition of sub-capabilities, essentially one for each View, plus modernization. Whilst modernization is not classically an architecture view, there is commonly a specialist requirement for modernization architecture that will include identification of appropriate transformation and transitional architecture patterns. The primary objective of all of the architecture sub-capabilities is to define realizable structure to meet the demand and, as discussed above, to optimize opportunities for modernization and provisioning. While there is no explicit enterprise architecture View called out, each architecture capability should be executed separately and iteratively for reference, portfolio, program, project and module, thereby defining progressive layers of standard functionality that will be common to the defined scope, as well as situation specific business functionality.

I will detail all the capabilities in a subsequent post.

Final remarks.

This high level view of the framework has attempted to list a set of principles and associated capabilities required to support the value chain illustrated in Part 1 of this extended blog post. What will hopefully have become clear is the need for architecture capabilities particularly to be involved throughout the value chain. This approach integrates all types of architecture (enterprise, service, solution, deployment . . . ) into the business improvement value chain and creates better opportunity to demonstrate the ROI on architecture. Further the approach prevents enterprise architecture particularly becoming divorced from mainstream business improvement and encourages a better balance of short term and strategic goals. What will not yet be fully clarified is how the framework is very strongly focused on realizing architecture in delivered services and solutions, as a series of successive collaborations. I will describe how this is done using a Lean approach in a subsequent post.

References: Oh No! We Need Another Practice Framework? Part 1

Beware the New Silos

Not Another Framework? Part 2

May 8, 2014 by David Sprott

The objectives of the framework are to:

Principles are foundational for any framework.

Principles should be enduring and lead to both excellent policy communication and policy interpretation in everyday situations. I also find it useful to classify principles by subject.

Capability Model

Most of the capabilities in the model are self-explanatory. However some need explanation:

I will detail all the capabilities in a subsequent post.

Final remarks.

References: Oh No! We Need Another Practice Framework? Part 1

Beware the New Silos

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

May 8, 2014May 7, 2014 by BizzDesign Staff

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

Does anonymity promote ill-informed consensus?

May 5, 2014 by Nick Malik

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?

May 5, 2014 by David Sprott

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

Ref 2: Navigating the SOA Open Standards Landscape Around Architecture

Oh No! We need another Practice Framework?

May 5, 2014 by David Sprott

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

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

Ref 1: Beware the New Silos

Ref 2: Navigating the SOA Open Standards Landscape Around Architecture

Public Sector Open Data via Information Sharing and Enterprise Architecture

March 25, 2014 by Guest Author

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;

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;
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
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

March 19, 2014 by Richard Sage

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

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:

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

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

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

Where 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

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?

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

January 14, 2014 by Brenda Michelson

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

July 28, 2014October 23, 2013 by David Sprott

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