Buy my book!
I created a list of books I would give someone if they told me they wanted to be a good EA. Read all of these and you will be a guru (or more likely an unguru).
With the upheaval of the economic downturn came a spate of mergers, acquisitions, divestitures, splits and buy-outs. The ensuing chaos of the resulting technology portfolios cannot really be overstated. Many surviving companies are just a mess. In normal times this may not be a big deal. But these aren’t normal times.
Next to the perennial favorite “What Enterprise Architecture is and/or is not,” I’m inclined to believe debates over frameworks are the hottest debates going right now. Why is that?
There are many challenges that CIO’s are facing in today’s cloudy, jargony, swirling maelstrom of Information Technology. But isn’t there something missing in the conversation that totally supersedes these challenges?
An architecture that is merely a PDF with a couple of generic line-box-arrow diagrams coupled with a few colorful “pancake” pictures isn’t really an architecture. It’s a marketing glossy. A white paper is too generic to be passed off as a real solution to a real problem.
There is much to recommend about changing how we create, deploy and offer our services and products to customers. Yet there is an entire consulting industry built around avoiding the pitfalls of cloud.
Title inflation/mis-direction is vermicious. Like a Knid.
As technology architecture professionals, we can only be successful and valuable to those who pay us if we frame our work in terms of capabilities at the outset. If we start with details, we’ll ultimately fail.
An architecture for a solution requires understanding the problem at hand well enough that solving it can be described in terms that everyone understands. The architect speaks in terms of capabilities, not products.
What would it take for your business to view IT as a valuable, essential partner instead of an annoying cost-center that they’re forced to deal with? Wouldn’t that be better for you and better for them?
Large technology organizations don’t simply become agile. They’re either agile or not. If they’re not, the path to being so is via change, often radical change at that.
The purpose of a company is to make money and to make that money while somehow imparting a positive effect to its customers. Can IT enable the business without a clearly laid out Vision? Without that sense of purpose, doesn’t IT typically make a mosh of things?
Architecture is about holistically describing the system of people, process and technology. It can be abstract and conceptual, or it can be concrete and detailed. But it is never merely a specific product set from a specific vendor.
Anything IT does should be seen as consistent. Using words like “Principle” with the definition most people have for it is a sure-fire way to disappoint folks. It turns out that instead of a iron clad ‘always-will-do’ thing, our Principles are merely suggestions.
Companies don’t “do” Social because they ultimately care about what their customers think. They “do” it because happy, engaged, evangelic customers contribute to the bottom line of the company while angry, disrespected, disinterested customers can kill the bottom line. The Enterprise is engaged in Social because Social is good for the Enterprise.
How does one sell something that doesn’t really exist in the physical world? Well you attach some sort of value to the thing. You establish a scenario under which, when used properly, the IT service will produce a cost savings or avoidance, or open a new line of revenue for your business. The IT service has to have dollars associated with it in order for the sell to even be possible. Hopefully they’re not red numbers. That makes it even harder.
A comprehensive architecture that is made up of things like mission, vision, goals, objectives, requirements, roles, activities, capabilities, services, technical components and yes, physical components is a holistic thing. It is something we bake, not something served up in piecemeal ingredients. We don’t eat flour and call it bread just because everyone around us happens to be an expert in flour.
You can quote all the learning management, skills management, performance management and professional development plan statistics you want, but we all know that title misdirection thrives in large Fortune 500 companies. It’s like a tapeworm in a Mexican restaurant: it is a target-rich environment. It isn’t endemic to IT, but it seems to be especially pernicious in this critical field.
For white collar career paths, the ability to identify, assess and diagnose business problems and then go on to prescribe and execute solutions absolutely demands thoughtful approaches that don’t magically come with the diploma. The education is a foundation. It is not a end unto itself.
On the back of my comments regarding metrics, a natural question arises. Namely, provided you are able to identify the correct measurements to take in the course of assessing the success or failure of any particular program, what is there to be said about interpretation of those measurements?
Despite the fact that the things we measure are often not related to the impact of our efforts on the business, this hasn’t stopped the relentless quest for metrics to feed legions of ravenous dashboard apps and Excel spreadsheets. In fact, they seem to have slowly become an end unto themselves.
You might be wondering what social media has to do with enterprise architecture. Apart from my argument that EA must include social as a functional area as well as a technical layer (as it is indisputably part of the business of business), the two areas share a common culture of obfuscation and jazz hands.
How can a business be effective and compete in the market if the leaders don’t have a clue what they’re spending? Is it because they don’t want to know, can’t know or just haven’t taken the time to know? I’m not sure which option is worse, to be honest.
A model is useful if it describes something in a context that renders a complex topic easier to digest for specific audience. Its purpose is to describe, to communicate. It is an expression of a viewpoint. It isn’t a detailed map or a blueprint. It is representative of a system, it doesn’t depict the system. It is an abstraction. I’m afraid we model too frequently as a cover for not actually producing things of value.
Suggesting architecture in general, or enterprise architecture in particular, doesn’t add value or is otherwise a fiscal black hole is akin to declaring that badly executed means discredits the ends. The objective of enhancing Business-IT alignment is a worthy one. Just because a bunch of charlatans over time have discredited one method of achieving that alignment doesn’t mean we shouldn’t bother.
With a weak crop of developers and architects, I’m concerned we’re growing a generation of bad IT managers, directors, VP’s and CIO/CTOs. I’m afraid our next generation leadership will be more concerned with the acronyms after their names, with frameworks and methodologies, than with the actual work of IT. That is, with theory rather than delivery.
Companies like innovation. But they won’t be early adopters of an ill-defined and constantly changing mindset. They’ll wait for it to calm down a bit, solidify and congeal. Then they’ll slowly roll it out and gradually update it over time. Suggesting they take an ADHD approach of constant churn and ongoing rip and replace of the latest EA theories doesn’t help them or us as practitioners.
EA, like the business and IT philosophies that underpin it, is constantly changing. If enterprise architecture is an architecture in which the system in question is the whole enterprise (including business processes, technologies, and information systems), then there will always be dynamism to it. These elements and components are under constant change.
We seem to measuring a lot of things lately. The sheer volume of status reports and dashboards and timelines and updates would seem to indicate we have lots of metrics being captured and reported. But I’ve seen firsthand how numbers are shoddily derived, over reported, incorrectly reused and re-reported and it doesn’t inspire confidence. What does it mean that leadership is basing decisions on these values?
There’s been quite a lot of recent discussion around the rise and fall and rise again of SOA as a means for constructing a services-based view of an enterprise or a solution. I totally support that idea. But to take it one step beyond mere technical views and introduce the common lexicon bridge, we need to be having discussion centered around the capabilities associated with those services.
The social experience, whether it is Facebook or Twitter or Foursquare or Flickr or the latest release of
The people who like to create solutions are typically not the best equipped to fully understand the context of the problem. They are structured by nature to take action, to find a way around the obstacle. Their gaze is fixed on the end result, the grand design of what will be in the future state. With this horizon-centric, forward looking perspective, the original purpose for the effort is usually sidelined.
Logic and the ability to think analytically are central to work in technology. That is the minimum requirement, the common denominator. But there are aspects of technology that require right brain thinking in order to be performed well. Intuition, free association, expression and risk taking are traits that are required for doing IT architecture well.
The vision is important. The purpose of the organization and its mission are critical to get right. Without it, how do you know what your objectives are? How do you know what you’re doing? How do you measure your activities? How do you know you’re being successful? How do you know you won’t be reorg’d into the unemployment line?
Architects often struggle to articulate what they do, what the value is that they provide. Consulting firms make millions helping folks with strategies to describe, highlight and demonstrate that value. How can it be that years and years into the maturation of Enterprise Architecture we still have problems telling the business why they need us?
EA doesn’t institute agility. When adopted and executed properly, it helps structure an enterprise so that it can move with agility if it chooses to do so. The practice of Enterprise Architecture enables a company to respond to change.
Why on earth would an enterprise place it’s architects in the AppDev organization? There they’ll be suffocated by groupthink geared to see solutions as the first step in addressing business problems. They’ll slowly begin to lose the context, the big picture. The discipline of architecture simply requires a different view of the world that vanishes from sight when the architect is mired in the muck and the lost in the weeds.
Anytime a technology or concept means different things to different people, it is effectively meaningless. Let Forrester and Burton/Gartner hash out whether SOA is alive or dead or morphed or evolved or reborn. Representing technical capabilities as services that people can understand will breach the business-IT language barrier.
If our enterprises operated like The Wiggles, we would all know the what’s, the when’s, the who’s and the why’s. If our systems and processes were as predictable as a children’s television program, we would know the how’s. How smoothly things would run if we all understood how to get predictable results from repeatable actions we all knew in advance?
The importance of social tools, social marketing and branding and socially interactive CRM cannot be overstated. What’s more, the incredible potential value to corporations in terms of knowledge management, office virtualization and organic competency growth dictates that social media and its associated tooling be incorporated into the way we do things in American business.
Frankly there is no way for IT to devise an IT solution if the business doesn’t know what they do, how they do it, or what they want to do in the future (i.e. the capabilities they want enabled). If those things are in place, the technology part can be incredibly easy.
The business shouldn’t be in the tool business. And for IT, when you come to believe that a solution is a tool, or when you buy into a situation where the business has purchased a “solution” in the form of a tool, then it is time to hand in your enterprise architect credentials.
The best technical solution is useless if it can’t be communicated by its creator or effectively championed in the face of opposition. Architecture places a premium on the ability to effectively analyze, design and communicate the architecture to those who would actually build it. Sadly too many in our profession have the title of architect while lacking this essential ingredient.
If you’re being measured against the standard of business success, why wouldn’t you want to perform as best you can in support of those metrics? If I’m the application architect, it should be in my self-interest to promote the best solution available to meet the requirements put forth by the business. Why would I actively pursue some other plan that ultimately does nothing to enhance my value to the organization?
When the demonstrable benefits of using an enterprise approach are self-evident to project teams, magic happens. There is this notion of street cred when it comes to how this stuff operates. I call this the soft power approach. It is very socially intensive. It involves a lot of time spent building relationships with project teams, business owners and segment leaders. It is all about invisible metrics.
I want to spend some time relating some of the things I’ve learned about working with enterprise architecture. There are far too many people running around calling themselves enterprise architects with no clue what it actually means. I think the IT industry itself does a poor job as a whole understanding the needs of its most important customer, the business. Quite honestly, I think the industry might often be wrong.
Want to know the real problem with your business?
Curious why you continue to have the same issues over and over again despite the greatest frameworks and models and methods and consultants? Wonder why your architects aren’t solving the problems you need to have solved to move the enterprise forward?
You may want to take a look at my book.
Available in hardcover, Kindle, iBook and everything else.
Is it a buggy whip moment for the consulting industry in light of #ai and #llms ? What should you do about it?
Check out the latest episode of Consultants Saying Things... #consulting #consultants
The Consultants Saying Things podcast now has a Patreon site with cool extra content...
Consulting can be a hard profession. Even harder if you don't actively manage your career. In the latest episode of #consultantssayingthings we take a look at the key ways to seize the reins of your career.
Dear @espn , your broadcast of the #gatorbowl, much like your commentary and analysis, is utterly unwatchable. How about an acknowledgement or apology?
Consultants Saying Things
