#eavoices

Why Open Source Is Really Disrupting Enterprise Software

by

I had an epiphany today about a major reason open source is disrupting enterprise software. This is perhaps one of those things that you have heard so much, you’ve gone numb to it. All the big giants are still alive and kicking, however; so is this really happening? The answer is yes, however the mechanics are not what you think. It is not simply just a cost play. The acquisition – one of the main weapons that big software vendors had to fight disruptors – is losing effectiveness. And that changes everything. Allow me to explain:

In the past, big vendors bought the smaller potential disruptors and got the code and customers. Cash disrupted the disruptor; investors got paid, and customers got the new technology as part of the big vendor’s larger suite. Everyone was happy.

In the open source model, the code is, well…..open source. The value is the people; and you can’t keep most people from leaving, which they will. Cool, talented open source developers don’t generally want to work for big, stoggie software vendors. Furthermore, customers bought into open source to avoid vendor lock in, so buying for the customers is not all that attractive either. This makes Hortonworks and Cloudera, for example, unattractive acquisition targets for the likes of IBM or Oracle. Hmmm…are you starting to see it?

Allow me to bring it all together: Open source is indeed erroding big software’s vendor’s profit; sure they are selling stuff, but open source disrupted sectors are not growing at the rate their stock price needs to keep investors happy. Investors will grow increasingly unhappy, cash will become scarce and big vendors will cut costs to prop up the bottom line and free up cash… for what – acquisitions? That doesn’t work like it used to. It’s is a downward spiral.

Read more

Form Follows Function on SPaMCast 446

by

It’s time for another appearance on Tom Cagley’s Software Process and Measurement (SPaMCast) podcast. This week’s episode, number 446, features Tom’s essay on questions, a powerful tool for coaches and facilitators. A Form Follows Function installment based on my post “Go-to People Considered Harmful” comes next and Kim Pries rounds out the podcast with a […]

The importance of cognitive dissonance with architects

by

Cognitive dissonance in psychology is the mental stress (discomfort) experienced by a person who simultaneously holds two or more contradictory beliefs, ideas, or values; when performing an action that contradicts one of those beliefs, ideas, or values; or when confronted with new information that contradicts one of the beliefs, ideas, and values. As such it … Continue reading The importance of cognitive dissonance with architects →

Trash or Treasure – What’s Your Legacy?

by

The topic of legacy systems is something of a contentious one. In most cases, a legacy is understood to be a good thing. What makes a system “legacy”? Is it a technical or business decision? A little over a year ago, Greger Wikstrand took a stab at clarifying the term with his post “Legacy systems, […]

Managing the fundamental interconnectedness of things with Enterprise Architecture

by

Enterprise Architecture is much more than a list of components. Too often one sees diagrams in slide decks that are either simple lists, a layered view of domains, or a graphical hierarchy. And these are supposed to represent the ‘Architecture’? These visualisations are good to use to inform on the scope and context, but they […]

The Present and Future of the ArchiMate® Language – Part 1

by

Welcome to the first in a series of blog posts on The Present and Future of the ArchiMate® Language. With the release of the ArchiMate 3.0 Specification last year, we now have a complete enterprise description language that has been adopted by architects worldwide in a wide range of organizations. It is now time for the ArchiMate Forum to reach out to users and better understand how the language is being used and how it should evolve. Therefore, the following post, like all others in this series, reflects the views of its authors, and will benefit from comments and discussion. You may refine, expand upon, or even disagree with elements of the post. Regardless, you will be shaping the future of the ArchiMate language.

So please, enjoy and engage!

Architecture Views & Layers of Abstraction and Details: How much is too much?

by
by Francis Uy, TOGAF 9, PMP


As an Enterprise architect, I find myself doing presentations to various levels of the company I am working with.  These presentations aim to recommend actions in order to support the company’s goals.  

My job is to make sure that decision makers are empowered with the right information to make the best choice at any given time. The most effective way for this information to elicit a speedy but quality-based decision is to recommend with the perspective of the person making the decision.  

In the book “3 Laws of Performance” by Steve Zaffron and Dave Logan they state that how people perform correlates to how the situation occurs to them.  This is very true also in how people make choices.  If you can understand how a particular situation occurs to your stakeholder and present information from that point of view, you are likely to get a better response from them.

For example, let’s say I am talking to a project management office (PMO) head.  It will be an easy conversation if I fully understand what his needs and concerns are. From a PMO’s point of view – his metrics are successful delivery of all the projects in his scope.  His concerns are that he has just in time visibility of project issues and risks so that he can support his project managers as soon as possible.  He would also want a tracking of the benefits each of the projects are promising and a visibility on when these will be met.

At his level, the layer of abstraction he needs will be primarily focused on the project views, the program views, or even perhaps the portfolio views. He would not need to see further details as what a project manager would see such as the work breakdown structure — unless one item there is now causing the delay of the benefit being delivered by a project.

Example below shows 2 levels of abstraction for the same set of projects.  The image on the left is a set of projects with their detailed steps.  The image on the right focuses on a summary of the total project health (status, costs, resources, etc)


On the other end of the spectrum, talking to a chief executive officer (CEO) of the company and understanding his concerns vis-a-vis the projects of the company will also ensure being able to successfully support him.  While, similar to the PMO, he does care about the benefits of all the projects in the company, he realistically only has bandwidth for the top 10-30% of them.  Hence ensuring that a filter is provided focusing on that will support his decision making.  Unlike the PMO though, his concerns are looking broader across the whole organization and even extends outside – specially if the company is listed on the stock market.  A key concern for the CEO is change management.  And inside change management a question of – will the projects or initiatives drive the right behavior we need in order to be a more competitive company. He will need views that show a holistic landscape of how all the projects are impacting various parts of his company.  Are we doing too many changes in one particular capability thereby decreasing the returns potential of a particular project?  Are we doing enough on the other important parts of the business?

Clearly, showing the CEO views beyond the whole company perspective — things like detailed design strategies or software details that software engineers and process owners use is definitely too much details.

The example below shows a view that the CEO would care about.  It is the business capability model for his company which shows the key capabilities (parents of business processes) needed to ensure business operations excellence.  Comparing this to the earlier views, a useful perspective is to see how many projects are in flight to improve the cost, risks, or business value of below capabilities. (see numbers overlaid on the capability)


Conclusion:

To be an effective architect, you need to know the key concerns of various levels and functions of the organization.  Presenting your data from their perspective will allow for an easier connection, collaboration, and decision making.

My challenge:  Next time you need to present or influence a key stakeholder stop first and think from their perspective and understand how is the issue or the situation occurring to them.



Talk to Us.

© Sinag Solutions

Unit 903, Antel Global Corporate Center, Julia Vargas Ave, 

Ortigas Center, Pasig City, Philippines, 1605

Office: (632) 956 5175