Scaling Agile for the Enterprise

by

Guest post by Tim Mattix, Mario Gouvea and Vikram Purohit With the ever-evolving software development landscape, large enterprises are increasingly “going Agile.” Agile is applicable to many scenarios; for example, Extreme Programming (XP) zeroes in on software engineering while wrapping in novel approaches to boost quality, and Scrum is the most widely adopted agile method. While both of these frameworks work well for software development teams, Agile is even suitable for less obvious initiatives, such […]

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. 

Desensitising the Introvert

by

image

A couple of weeks ago I met up with Martin Howitt for the first time. We’ve been ‘twitter friends’ for a while so it was good to meet in real life and talk about stuff. At the time Martin was on PS Launchpad and we talked about presentations and introversion (I think we’d probably exchanged tweets about it previously).

During our conversation I said something along the lines of “I like to try and desensitise my introvert”. Saying these words out loud to myself for the first time really resonated with me and i’ve been mulling over a blog post ever since, so here it is.

The Young Introvert

I was very shy when i was young and very quiet. I think a lot of people thought I was rude because i was so quiet. Still today i’m pretty sure that there are people i know and like who think that i’m rude and/or don’t like them because i’m shy.

My introversion used to manifest itself in odd ways.

Once when I was a kid my extended family had a get together at a holiday cottage. We got there late and there was a buffet laid out. I was starving, but the thought of going across a room of people into another room full of people where the food was and possibly having to talk to someone was so scary i just sat where i was and didn’t move until it was time to go to bed.

When i was a kid i did Judo, for a bit. The second grading i had was in a big local sports hall with about 100 other kids and several hundred parents sitting watching the fights. As you can imagine this was not a scenario in which i was comfortable. My first fight was with a much shorter kid. before the fight started i’d decided i would try and lunge forward grab his lower leg and lift him up and backwards onto his back to win.It didn’t go to plan and i somehow managed to get kicked hard in the groin. I cried, but the intensity and duration of my tears was of a magnitude much greater than the pain. The kick had broken the facade i was maintaining of being ok with being watched by dozens of people. The kick had woken up my introvert and now it (I) was crying.

Being an introvert doesn’t mean you act like an introvert all the time. sometimes you have a rush of misplaced courage.

When i was 16/17 i was in a band, we were called Battenburg and we got a gig supporting Mogwai. The singer wanted to be damon albarn, the other guitarist wanted to be graham coxon, the bass player wanted to be noel gallagher, the drummer wanted to be in a boy band and I wanted to be anywhere else on earth other than on a stage. And yet, I loved being on the stage. I liken this apparent contradiction to my childhood love of abseiling, whilst being shit scared of height (to the point of being frozen and embarrassingly immobile for prolonged periods whilst trying to climb things). It scares you and it gives you a buzz, adrenalin I guess.

So, we were doing this gig, but we didn’t have enough material for a set. One day during a practice I played and sang ‘Champagne Supernova’ by Oasis and the rest of the band convinced me to sing this during our set as a way of padding out the time.

I f***ed it up completely. About 30 seconds into the song I realised what i was doing and it fell apart. I played the wrong chord, my throat decided it was a good time to try and close itself up, I managed a half recovery and limped to the end of the song and got a charitable round of applause at the end. This story is the reason why there is a picture of Wile E Coyote at the top of this post. because sometimes I make the leap that my introvert wouldn’t let me make and its ok for a bit, but then your introvert finds out you look down and find you aren’t standing on anything, the ledge of confidence you had just peters out.

But guess what, I spent the rest of the night oscillating between buzzing and cringing, buzzing and cringing. This is a pattern I repeat constantly.

The Shower Cringe

Say I’m in a meeting/interview/meeting someone new/out with friends/doing something that involves any social interaction, the next morning i can guarantee what will happen. I’ll get up, have some breakfast, get in the shower and what i said the day/night before will be processed in my mind and i’ll cringe (mentally mostly, but sometimes physically), why did i say that? why did i do that? what was i thinking? what an idiot? and then its gone and i get on with what i’m doing, safe in the knowledge that this will happen next time. So much so that i often have a pre-cringe cringe, whilst i’m doing or saying something, my mind goes ‘oh hang on i’m going to remember that so you can have a cringey shower tomorrow’ and I then pre-cringe ‘you f-ing prat, why did you say that?’ 

Desensitising My Introvert

Looking back over the last few paragraphs i’m already cringing to myself. what if someone reads this drivel? what if someone i know/like/respect reads this? I’m going to take a deep breath and blow that idea out of my head via my mouth.

Over the last couple of years i’ve started a new hobby and its the hobby that my chat with Martin helped me name, I like to desensitise my introvert.

A couple of years ago I set myself a 10 week challenge to write and record 1 song a week based on ideas submitted on a facebook page. i called it ‘songs as a service’ and its here. It was a lot of fun but also very scary. friends, family, work colleagues were all aware that i was doing it the thought of it filled me with anxiety, nervousness and dread, but i did it and since i did it i feel my introvert is slightly smaller than it used to be. 

Over the past couple of years i wrote a few ebooks, one about ‘How to be a dick‘ and one documenting 30 days using Brian Eno’s Oblique Strategies at work Both were meant to be humorous and light-hearted, but both required putting myself out there in a way i’d not done before. Again, I feel like my introvert is a little smaller thanks to doing this.

At work, presentations used to give me the same feeling I had when I did the Judo grading, but over the past few years i’ve consciously sought out any opportunity to present, i’m now at the stage where it feels more like the buzz when i sang ‘Champagne Supernova’ but without the f*** up. I see that as an improvement 🙂

Recently a choir has started at work. the thought of singing in front of work colleagues filled me with dread and still does every time i do it. but i get the buzz and I deal with the cringes.

Just this week due to a bizarre mix up a colleague at work was under the misapprehension that I might be up for doing a bit of acting in his local amateur dramatics group. It is not something I’d thought about (except maybe in nightmares), but as he was talking to me about it I thought, this is exactly the sort of thing i wouldn’t do (introvert in my head says ‘run! run for your life!), which i why i’m now going to do it 🙂

Hell is other People

So wrote Sartre. I like people but i am, deep down, quite scared of them. People have written before about how extroverts get energy from interactions with other people whilst introverts give energy to interactions with other people and i think there is some truth in it.

My best, most invigorating days are when I’ve spent the most time talking to people I find interesting about interesting topics and/or collaborating on interesting work with them, they are also the days in which I’m most drained. 

Being introverted will always be my default position, I am much more likely to say ‘Hi!’ to someone i know if i meet them in the street and keep on walking, than I am to stop and have a 5 minute conversation with them. But I feel that by consciously trying to desensitise my introvert i’m slowly changing the ratio against the introvert.

Categories Uncategorized

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

Assessing Business Architecture’s Value Contribution

by

I have been working on a business architecture practice dashboard to help BA leaders manage and grow their practice. The dashboard contains three basic metric types: impact, value, and activity. Each type provides valuable insight into business architecture’s performance and organizational impact. In this post, I focus on value contribution metrics. Value contribution metrics report […]

Connecting Business and IT

by

There is sometimes a disconnection between the business strategy and the IT strategy of a company and that inevitably implies unexpected effects like e.g. difficulties for IT to deliver solutions in due time, on scope, on budget or with the requested level of quality.  One of the things the business part of a company wants […]

The Value of Enterprise Architecture in Managing Risk, Compliance and Security

by

In my first blog post of 2014, I described how enterprise architecture delivers value in its relationship with other disciplines within the enterprise. I showed you the picture below, outlining this context of EA, and described the main focus areas of BiZZdesign’s EA service line in 2014:

  1. Realizing the enterprise strategy.

  2. Supporting strategic investment decisions.

  3. Fostering enterprise agility.

  4. Leveraging technological opportunities.

  5. Controlling risk and ensuring compliance.

 

Figure 1. Enterprise Architecture in Context

In a subsequent blog post on value-driven enterprise architecture, I focused on the right-hand side of this picture, zooming on the first three of these topics, and addressed how EA provides business value by connecting the dots between strategy, capability-based planning, portfolio management, program management, and operational delivery and change processes.

Let us now have a look at the left-hand side of the figure, in particular the value of EA in managing risk, compliance and security in the enterprise (nr. 5 in the figure).

Strategic insight into risk

To be in control of the risks you run, the first thing you need is strategic insight in your organization from a risk management perspective. This requires having a consistent and up-to-date overview of your current landscape of products, processes, applications, and infrastructure, and all related risk & security aspects. Without such an overview, you are flying blind in the fog. C-level management cannot fulfill its responsibilities without knowing what the main risk-related issues are.

Having an understanding of these relationships also helps you in assessing the effects of business decisions. This provides the business with a clear insight in the enterprise risks related to, for example, introducing new products and initiatives, outsourcing business processes or IT systems, or assimilating another organization after a merger. Thus, they can weigh the risk propensity of the enterprise against the potential consequences.

Moreover, the propagation of risks throughout the enterprise is of great concern to executives and operational management. Risks in one area may entail risks in another. For example, what are the potential ripple effects of a system failure, break-in, power outage, fraud or other mishap on critical business processes, services, clients, partners, markets, …? Enterprise architecture helps you to create insight in these relations and dependencies, and thus avoid or mitigate potential disasters.

Business-driven security and risk management

A related area in which EA provides tangible business value is in aligning security and risk management with business goals and objectives. Many organizations find it difficult to decide on the right level of security measures, and business managers often see this as a technical issue that is left to the IT people. They, in turn, don’t want to take any risk and create gold-plated solutions that are quite secure but also very expensive (and often rather unfriendly towards users).

Better alignment between business goals, architectural decisions and technical implementation helps the organization to spend its security budget wisely, focused on business-relevant risks. This may even lead to both cost savings and lower risks at the same time, because you do not invest in overly strong security measures for unimportant stuff, leaving more budget to protect the things your enterprise really cares about.

Moreover, security is not something that can be ‘tacked on’ afterwards. Inherently insecure architectures and systems are very difficult to fix later on. Rather, security and risk management should be designed in from the start, using the business goals of the enterprise to decide on appropriate measures.

Regulatory compliance and auditing

Another common reason for having a mature EA practice, especially in heavily regulated sectors such as banking and insurance, is regulatory compliance. Central banks and other regulatory bodies mandate or at least strongly recommend that financial institutions have a well-established EA practice, to ensure they are in control of their operation. They may even audit these architectures or use them in other ways to assess the risks the organization runs. Of course, internal auditors, CISO’s, and risk managers benefit from using EA artifacts as well. The insights into enterprise-wide relations and dependencies that these provide are important inputs for their tasks.

Implementing standards and policies such as SEPA, Solvency II, Basel III and others requires enterprise-wide coordination, visibility and traceability from boardroom-level decisions on e.g. risk appetite of the organization, down to the implementation of measures and controls in business processes and IT systems. Enterprise architecture as a practice, and enterprise architecture models that capture these relations, are indispensable to manage the wide-ranging impact of such developments.

Next steps

To benefit fully from the use of enterprise architecture in the context of security, compliance and risk management, we suggest that you focus on the following:

  • Align security and risk management with business strategy. Always view security and risk measures from the perspective of the business value they add.

  • Capture and visualize risk and security aspects of your organization. Visualize hazards, risks and mitigation measures in relation to the overall architecture and business strategy.

  • Measure and visualize the impact of risks and use these insights for decision making. Visualize data from e.g. penetration tests and use this to decide at the business level about necessary IT measures.

  • Prioritize security projects. Calculate the business value and impact of security projects and use this to make a prioritization of IT measures.

  • Use effective tool support. Software for fast and clear modeling, analyzing and visualizing provides the necessary insights. For example, BiZZdesign Architect, our easy-to-use, powerful tool for enterprise architecture and enterprise risk & security management.

Categories Uncategorized

Why EA needs to influence IT and the Business

by

Last week I talked about the differences between Service Catalog and Service Portfolio. This week is about the span of control Enterprise Architecture needs to have within an organization to be successful.
Everyone is well aware of the fact that Enter…

Categories Uncategorized

Lessons Learned: A Look Back at Our 2014 Troux Worldwide Conference

by

bg outline

By: Ben Geller, VP Marketing, Troux

sticky 043014 (3) blogIt’s been a month since Troux hosted more than 200 customers at our worldwide conference in Austin to talk about ways to make enterprise architecture (EA) a must-have business capability. Now that everyone has digested their Texas BBQ and cleared out their inboxes, we’d like to reflect back on what attendees experienced at this year’s Troux Worldwide Conference.

What’s all the fuss about?

We started the Worldwide Conference four years ago to bring together customers, partners, and professionals involved in Enterprise Architecture (EA) for networking and joint learning with a focus on delivering rapid results with Troux Enterprise Portfolio Management (EPM) solutions. That event has become an annual function that drives EA discussions and a lot of knowledge sharing.

The theme for the 2014 conference was Making EA Stick and featured presentations from over a dozen Troux clients and partners. We were thrilled to welcome Amway, ANZ Bank, Apptio, Atos, BDNA, Dell, Fidelity Investments, HSBC, JetBlue, MetLife, Molina Healthcare, Saudi Airlines and VMware to share key learnings and outcomes achieved on their EA journey. In addition, the Troux team presented keynotes, demos and best practice sessions that walked attendees through how to use EA to drive strategic decision-making and business success.

Rather than tell you what we thought of the experience, we gathered some key conference takeaways from attendees:

Cary Brown, Molina Healthcare said:

  • Think in terms of business value: To align EA to business outcomes it is important that you think in terms of the problems you are solving for each area as if you worked there and demonstrate EA’s value every step of the way, making them equally as successful in helping the company achieve their goals.
  • Change your own processes where it matters most: Just because you’ve done something a certain way doesn’t mean you need to always do it that way. Your business changes and EA needs to change along with it.
  • Answer Important Questions: Once you know the chief challenges in your key business areas you can clearly identify the questions that need answering the most, then drive EA towards answering those questions.

Amway’s Dave Reinhard summed up his takeaways as:

  • Sharing experiences on EPM with companies navigating new and mature programs makes it a lot easier to put headlights on our own program and avoid potential problems.
  • Understanding comes with communication. Problems come without it.
  • There always seems to be just one more facet that I hadn’t thought of before.

In his blog, Intact Technology, 2014 Worldwide Conference, Corey Balko wrote:

Great architects should become great communicators. The common theme heard throughout the conference was how to communicate value back to the organization. There was no shortage of valuable data, but we need to understand that it is not about the data. The way we usually communicate is hurting us. We struggle with communicating the value of EA.

Read Corey’s entire blog post for a list of pitfalls to avoid and for tips on how to turn your data into a story that people want to hear.

Keep the EA learnings going! Join us for Troux Directions EMEA 2014

Join us in London on October 1st for the 2014 Troux Directions EMEA Conference. This event is designed for business and IT executives who are actively involved in defining business strategy for their company. Troux Directions lets you enjoy peer networking and learning with a focus on delivering rapid business results with Troux EPM solutions.

Categories Uncategorized