Effectiveness for enterprise-effectiveness

Keep it simple. Simple, yet not simplistic. Acknowledge the complexity, yet don’t ever push that complexity in people’s faces. (Not until they’re ready for it and choose to face it, anyway.) Help people find their own effectiveness about creating effectiveness.

Never Waste A Good Crisis

The title of this post is a bit of advice I first heard many years ago, while working on an Enterprise Architecture review of a troubled software development effort.  Never waste a good crisis.

Of course, no crisis is good for the person going through it.  Be compassionate.  And I’m not talking about a personal crisis like the death of a loved one.  I’m talking about a crisis in business, like when a company changes strategy leaving customers out in the cold, or when a new technology simply fails to deliver any value, leaving the champion with less buy-in from his business stakeholders.

These are the little crises of business.  It often starts with someone taking a risk that doesn’t produce an hoped-for return.  If that someone is a senior leader, and they are smart, they have already collected their bonus or promotion and moved on, so they won’t get the blow-back from their own failure.  But just as often, the person who took a risk is still around to get hit with “blame and shame.”

Unhealthy as it is in a corporate environment, blame and shame is common.  When something goes wrong, someone takes the fall.

But for an influencer like an Enterprise Architect, a crisis can be a good thing.  Why?  Because we are change agents.  And people won’t change unless they are forced to change.  John Kotter, in his book “Leading Change” suggests that one of the greatest obstacles to change is complacency.  Change just isn’t urgent enough.  He’s completely right, and a crisis is often what is needed to break through complacency.

So a good change agent has a dozen different changes all queued up, ready to go.  Well thought out, well planned, well designed changes.  Some little, like getting your boss to agree to buy you a new Surface Pro 3, and some big, like a hacker waking up your leadership to the notion data security. 

To take advantage of a crisis, you have to be ready.  Have your arrows sharpened and sitting in your quiver, ready to go.  During a crisis, you may get exactly one shot to propose an idea, and it may not be the moment you expect.  There won’t be a “right” time.  Just the opportune time.  So be prepared.

And when the crisis comes, strike.

On that note, I’m leaving Microsoft. 

I’ve had the great pleasure of being part of the Microsoft family for eleven years now.  As many of my friends know, I was a dot-com entrepreneur back in the 90’s and had a great run at two start-ups in a row.  It was exciting but risky.  My children were very small and responsibilities to my family meant that I needed to curtail the risk for a while.  So I sought a “safe port in a storm” by joining Microsoft.  It served me well.  During the doldrum years and all the way into the Great Recession, I rode with Microsoft, pouring my energy into becoming the best Enterprise Architect I could be.

And for the past few years, I’ve been fortunate to be part of Microsoft Consulting, while the company experimented with providing Enterprise Architecture as a consulting program.  The ESP program has been through many lives in the past few years, and it is still “figuring itself out”, especially with the new “Devices and Services” world Microsoft has chosen for itself.  I’ve met some of the smartest, most amazing architects, project leaders, and yes, even sales professionals while working inside Microsoft Consulting, and I’ve learned a great deal.

But it’s time.  The economy is back.  Enterprise Architecture is on the rise, and I see opportunities to provide Enterprise Architecture service that are outside of Microsoft’s strategic focus. 

So I’m moving on to create my own Enterprise Architecture practice as a compliment to Microsoft Consulting.  I am applying to become a Microsoft Partner, and will work happily with Microsoft customers, but I’ll no longer be limited to working solely in the Microsoft model.  I’ll be looking for other architects willing to take this journey with me. 

Moreover, as many of you know, Enterprise Architecture is of tremendous value in companies that don’t have strong IT strategy and planning DNA.  These can be very large companies that are not IT focused, like transportation companies or retailers, or midsized companies that have never really gotten hold of the concept of strategic planning.  It can even include start-up firms that need to spend wisely and move quickly.  These players are an excellent market for a Vanguard EA, and I’m going for it with an established business and technical architecture process.

So if you wish to continue to follow me, reach out and connect with me on LinkedIn.  http://linkedin.com/in/nickmalik

I will continue blogging on a new platform as soon as I get things set up.  If I’m able, I’ll bring across the EA-specific articles from this blog to that site as well. 

It’s been a good run, but I’m awake from my own complacency, and I’m not going to waste a good crisis.

Never Waste A Good Crisis

The title of this post is a bit of advice I first heard many years ago, while working on an Enterprise Architecture review of a troubled software development effort.  Never waste a good crisis. Of course, no crisis is good for the person going through it.  Be compassionate.  And I’m not talking about a personal…

BankSpeak

#WorldBank #DataModel I recently went through a data modelling exercise, underlining and classifying the nouns in a set of functional design documents for a large client project. So I was interested to read an article based on an analysis of World Bank reports over the last fifty years, based on a similar technique. Some of the authors’ key findings resonated with me, because I have seen similar trends in the domain of enterprise architecture.

The article looks at the changes in language and style during the history of the World Bank. For the first couple of decades, its reports were factual and concrete, and the nouns were specific – investments created assets and produced measurable outcomes, grounded in space and time. The dominant note is of factual precision – demarcating past accomplishments, current actions, necessary policies and future projects – with a clear sense of cause and effect.

“A clear link is established between empirical knowledge, money flows and industrial constructions: knowledge is associated with physical presence in situ, and with calculations conducted in the Bank’s headquarters; money flows involve the negotiation of loans and investments with individual states; and the construction of ports, energy plants, etc., is the result of the whole process. In this eminently temporal sequence, a strong sense of causality links expertise, loans, investments, and material realizations.”

In recent decades, the Bank’s language has changed, becoming more abstract, more distant from concrete social life. The focus has shifted from physical assets (hydroelectric dams) to financial ones (loans guarantees), and from projects to ‘strategies’. Both objectives (such as ‘poverty reduction’) and solutions (such as ‘education’, ‘structural adjustment’) are disengaged from any specificity: they are the same for everybody, everywhere. The authors refer to this as a ‘bureaucratization’ of the Bank’s discourse.

“This recurrent transmutation of social forces into abstractions turns the World Bank Reports into strangely metaphysical documents, whose protagonists are often not economic agents, but principles—and principles of so universal a nature, it’s impossible to oppose them. Levelling the playing field on global issues: no one will ever object to these words (although, of course, no one will ever be able to say what they really mean, either). They are so general, these ideas, they’re usually in the singular: development, governance, management, cooperation. … There is only one way to do things: one development path; one type of management; one form of cooperation.”

I have seen architectural documents that could be described in similar terms – full of high-level generalizations and supposedly universal principles, which provide little real sense of the underlying business and its requirements. Of course, there is sometimes a need for models that abstract away from the specifics of space and time: for example, a global organization may wish to establish a global set of capabilities and common services, which will support local variations in market conditions and business practices. But architects are not always immune to the lure of abstract bureaucracy.

In Bankspeak, causality and factuality is replaced by an accumulation of what the authors (citing Boltanski and Chiapello) call management discourse. For example, the term ‘poverty’ is linked to terms you might expect: ‘population’, ’employment’, ‘agriculture’ and ‘resources’. However the term ‘poverty reduction’ is linked with a flood of management terms: ‘strategies’, ‘programmes’, ‘policies’, ‘focus’, ‘key’, ‘management’, ‘report’, ‘goals’, ‘approach’, ‘projects’, ‘frameworks’, ‘priorities’, ‘papers’.

We could doubtless find a similar flood of management terms in certain enterprise architecture writings. However, while these management terms do have a proper role in architectural discourse, we must be careful not to let them take precedence over the things that really matter. We need to pay attention to business goals, and not just to the concept of “business goal”.


Franco Moretti and Dominique Pestre, BankSpeak – The Language of World Bank Reports (New Left Review 92, March-April 2015)

Related post: Deconstructing the Grammar of Business (June 2009)

BankSpeak

#WorldBank #DataModel I recently went through a data modelling exercise, underlining and classifying the nouns in a set of functional design documents for a large client project. So I was interested to read an article based on an analysis of World Bank reports over the last fifty years, based on a similar technique. Some of the authors’ key findings resonated with me, because I have seen similar trends in the domain of enterprise architecture.

The article looks at the changes in language and style during the history of the World Bank. For the first couple of decades, its reports were factual and concrete, and the nouns were specific – investments created assets and produced measurable outcomes, grounded in space and time. The dominant note is of factual precision – demarcating past accomplishments, current actions, necessary policies and future projects – with a clear sense of cause and effect.

“A clear link is established between empirical knowledge, money flows and industrial constructions: knowledge is associated with physical presence in situ, and with calculations conducted in the Bank’s headquarters; money flows involve the negotiation of loans and investments with individual states; and the construction of ports, energy plants, etc., is the result of the whole process. In this eminently temporal sequence, a strong sense of causality links expertise, loans, investments, and material realizations.”

In recent decades, the Bank’s language has changed, becoming more abstract, more distant from concrete social life. The focus has shifted from physical assets (hydroelectric dams) to financial ones (loans guarantees), and from projects to ‘strategies’. Both objectives (such as ‘poverty reduction’) and solutions (such as ‘education’, ‘structural adjustment’) are disengaged from any specificity: they are the same for everybody, everywhere. The authors refer to this as a ‘bureaucratization’ of the Bank’s discourse.

“This recurrent transmutation of social forces into abstractions turns the World Bank Reports into strangely metaphysical documents, whose protagonists are often not economic agents, but principles—and principles of so universal a nature, it’s impossible to oppose them. Levelling the playing field on global issues: no one will ever object to these words (although, of course, no one will ever be able to say what they really mean, either). They are so general, these ideas, they’re usually in the singular: development, governance, management, cooperation. … There is only one way to do things: one development path; one type of management; one form of cooperation.”

I have seen architectural documents that could be described in similar terms – full of high-level generalizations and supposedly universal principles, which provide little real sense of the underlying business and its requirements. Of course, there is sometimes a need for models that abstract away from the specifics of space and time: for example, a global organization may wish to establish a global set of capabilities and common services, which will support local variations in market conditions and business practices. But architects are not always immune to the lure of abstract bureaucracy.

In Bankspeak, causality and factuality is replaced by an accumulation of what the authors (citing Boltanski and Chiapello) call management discourse. For example, the term ‘poverty’ is linked to terms you might expect: ‘population’, ’employment’, ‘agriculture’ and ‘resources’. However the term ‘poverty reduction’ is linked with a flood of management terms: ‘strategies’, ‘programmes’, ‘policies’, ‘focus’, ‘key’, ‘management’, ‘report’, ‘goals’, ‘approach’, ‘projects’, ‘frameworks’, ‘priorities’, ‘papers’.

We could doubtless find a similar flood of management terms in certain enterprise architecture writings. However, while these management terms do have a proper role in architectural discourse, we must be careful not to let them take precedence over the things that really matter. We need to pay attention to business goals, and not just to the concept of “business goal”.


Franco Moretti and Dominique Pestre, BankSpeak – The Language of World Bank Reports (New Left Review 92, March-April 2015)

Related post: Deconstructing the Grammar of Business (June 2009)

Putting Your Best Foot Forward

bg outline

By: Ben Geller, VP Marketing, Troux

right stuff 051215 blogEvery year, right around this time, a buzz zips through the enterprise architecture community when InfoWorld, Forrester Research and the Penn State University Center for Enterprise Architecture open their collective call for entries for the Enterprise Architecture Awards (a program now in its sixth year).  Enterprise architects and business leaders alike snap to attention and reflect on how their organization has leveraged and benefited from EA efforts over the past year. Since we’re about one month out from the deadline for nominations (here’s your heads up that they close on Friday, June 15), we thought it would be instructive and timely to lay out a few baseline tips for what makes up a successful entry, taking into account similarities between past winners that are both Troux customers and unaffiliated role models for the discipline.

1) Focus on business impact.

And to put a finer point on it, measurable impact. This isn’t always possible if an organization is just getting its EA program structured, off the ground and running, but quantifiable results on both the IT and broader business planes make entries exceptionally more impactful and explicable.

As an example on the IT savings layer, in their entry last year, Troux customer Dell conservatively estimated resulting IT savings at $152 million. That’s a hard number to ignore. They also supplemented the IT savings with more qualitative business results in the fact that they transformed their business and services offerings to be optimized for global, end-to-end solutions rather than siloed technology products.

An entry recognized from The Australia Post boasted impressive diversity in measurable impact: Projected IT savings of A$40 million over five years (with A$5 million already realized), estimated annual carbon emission reduction of 6,030 tons and a predicted increase from 1.4 million to 4 million registered customers over the span of a year. For those keeping count, that’s a 186 percent increase in customer base.

Even if you have to rely on estimates or projections to demonstrate business impact, go for it, provided you have the realistic figures and rationale to back it up.

2) Prove innovative thinking.

As we’ve mentioned previously, basic transparency into a company’s IT operations, resources and processes is a major victory. Cost-cutting, eliminating redundant technologies and making smarter IT investments based on that transparency are even more admirable results. But what the judges are looking for more and more every year in this program is reaching the next level – doing something truly innovative that hasn’t been seen in the enterprise environment before. How are you connecting EA to digitization, BYOD, the IoT or, cybersecurity or an even more emergent trend or field?

3) Choose a human face for your story.

Even though this isn’t an awards program recognizing individual achievement and you don’t have to mention specific names, it pays to personify your program and broadly give credit where it’s due. The “face” of your story could be your CIO, your enterprise architect or even a diverse team of experts. Whoever it is, they should embody the collaboration, vision, leadership and other traits that provide the foundation for any strategic business project.

Molina Healthcare’s (another Troux customer) “face” for their entry last year was an eight-member team of enterprise, information and solution architects that work with senior stakeholders leading business units and strategic projects. These eight conduits between IT and the business are the heroes of Molina’s EA (and award submission) success.  (click here to listen to their story)



New Call-to-action

4) Use unique industry variables to your advantage.

To some extent, most IT organizations face similar questions, end goals, trials and tribulations. But the market obstacles that face each business can be very different and exclusive. Take Allstate Insurance’s 2014 entry for example – it brought in references to rapidly-changing trends like telematics and the connected car. The chances of another candidate being able to play off those exact same trends were slim to none. What makes your industry unique and forces your EA team to be more creative, flexible, agile or business savvy?

5) If you can bring your business counterparts along for the ride, all the better.

We’re going to reach back to 2013 for an example of what we mean here. There’s one key point from the description of Cisco’s entry that’s uber-impressive: “[The EA practice] has also expanded the use of the model to support other parts of the business, moving everyone toward a shared business outcome. Going forward, Cisco plans to connect the business architecture initiative to other planning functions.”

Believe it or not, EA can apply to integral parts of running a company outside of the IT realm. If you find yourself applying or extending those same principles to achieve success in other business processes and functions, include that in your entry to give it another dimension.

So there you have it – a few pieces of wisdom we’ve picked up over our years of participating in the Enterprise Architecture Awards. Best of luck in your submissions; we’ll see you in the arena!



New Call-to-action

RBPEA: Attachment, non-attachment, non-detachment

It’d be mid-evening by now, I guess, as I wander down to the platform for the tube-train home. As the train-doors open, there’s a cluster of mostly Asian lads down at this end of the train, happily joshing with each

RBPEA: The dangers of ‘anything-centrism’

An architecture may have a centre – in fact most types of architecture work best if there’s a central theme or parti. Yet the process of architecting must not have a single centre – and that distinction is crucial, especially as we

RBPEA: Where’s the plan?

This one came through from a colleague on the Twitterstream a couple days back, presumably somewhat channeling John Lennon: Imagine no possessions, we’d all love to see the plan And yeah, it’s a concern (complaint?) I get a lot about

Sharing the Solution Domain Taxonomy

Sometimes, Enterprise Architecture efforts fail.  This is no surprise to folks in the EA business.  This failure occurred slowly, back in 2007 and 2008.  But it did occur.  It took me a while to realize it. 

I had developed a method useful for Application Portfolio Management as well as for Service Oriented Architecture called “Solution Domains”.  The method is good.  It’s a framework and taxonomy for high level descriptions of software so that generalized services can be created AND so that the portfolio of applications can be rationalized.

The method is good.  But I failed to position it’s use in the appropriate enterprise program in the appropriate way.  I failed.  Not the method.  Where we used the method, it worked brilliantly. 

I’ve learned from my mistakes, but being unwilling to let a good thing go to waste, I’m sharing the Solution Domain taxonomy with the world.  It’s not patentable (I tried).  It is useful, however, because it is a part of a business method that supports Application Portfolio Management in a completely technology agnostic manner as well as Middle-Out SOA.

I’ve put the entire taxonomy on my Enterprise Business Motivation Model site at: http://motivationmodel.com/wp/application-portfolio-management-and-solution-domains/ 

I may return here, at some point, and provide further details on how it can be effectively used.  For now, back to work!