Not sure if I should be depressed or relieved after reading the The Enterprise Architecture Paradox. On one hand it smacks of futility of EA efforts and illustrates the frustrations of EA work, on the other it proves that we are not alone in our “journey”. For the time being we need to keep pushing and continue to realize those invisible wins. Don’t Stop Believing! Worth reading.
It was with great interest that I read Nick Malik’s post “What makes models interesting“. In his post, Nick speaks about his EBMM model but the fundamental concepts of approaching modeling and the questions it poses are more universal and applicable to all kinds of enterprise modeling. Whether it is EBMM, ArchiMate, UML, or any other “notation du jour” there is always that temptation to add more to the model. I think it is human nature. After we model something with a given standard, we become familiar with the contents of the model and over time it starts to feel as too obvious to be useful. This in turn leads to temptation to “improve” it. Sometimes improvements are warranted and sometimes they aren’t. If they are driven by desire to answer some specific questions that contribute to enterprise value, then great, but if they are driven primarily by model purity or general quest for more detail then you may be well advised to take a pause. We don’t want to model just for the sake of modeling. Instead, we want to use the models for strategic and tactical planning, for architecture alignment across the enterprise, for optimization of operations etc. Just to be sure, I’m talking about enterprise models here. Models that aim to illustrate where the enterprise is and where the enterprise is going. Those who have been exposed to enterprise architecture at a large organization know what I’m talking about. They also know how challenging that is. The reason I’m making that distinction is because when dealing with models that describe specific solution you may want to get to whatever level of detail is appropriate to explain the solution to your audience. If you try the same for the enterprise-level models you may find that it is extremely difficult to tie everything together.
I know that some will question the wisdom of even having the enterprise-wide models and will tell me that I am better off to focus on a specific area or on a specific problem. Well, in the end it all comes down to what questions I am trying to answer doesn’t it? So back to the questions… The questions that we ask at the enterprise level are different from questions asked during implementation of a solution. Some of the enterprise-level questions may be:
- Where are the undesirable system redundancies?
- What systems rely on non-standard technology?
- Which systems cost more to operate?
- Which critical business processes are supported by high availability applications/services?
Some of the solution-level questions may be:
- What type of interface is used to access a service?
- Is service consumed synchronously or asynchronously?
- What components are used to build an application?
All good questions, but not all of them can or should be answered with the same model. In other words, models have to be fit for purpose. Attempts to mix different concerns usually end in a mess. …And then there is this pesky law of diminishing returns. How much work do we want to put into the upkeep of the models? More detail means every time that detail changes the model should be updated, right? Now take that to the scale of a large enterprise with many system inter-dependencies and it translates into a massive amount of work. Detection of those changes alone is a challenge too because in a large enterprise change tends to be constant and occur in many places at the same time.
If we assume that the architects are the keepers of the models, we need to ask ourselves how much of their time should be spent on keeping the models useful. Useful models should be current and given the breadth and rate of change it implies a significant effort. It seems that architect’s time would be better spent on model driven analysis and planning (a.k.a. architecting). Otherwise, we are approaching the territory of modeling for the sake of modeling, where we devote most of the energy to maintaining the models and not having time to actually use them.
So what practical advice can we employ for enterprise-level modeling? Here are my suggestions:
- Ask yourself what questions are you trying to answer with the model and prioritize them. Set out to build models for a few high-priority questions first.
- Establish a set of modeling rules that you can apply on top of your favorite modeling notation. This approach will keep you at the consistent level and promote discipline needed to build enterprise-wide models incrementally.
- Resist putting more detail into models at least until you can be sure what it takes to maintain them at the current level.
- Keep verifying that the models help you answer the questions for which they were built and adjust accordingly.
- Rinse and repeat, starting with step 1.
Recently, I attended the Building Business Capability (BBC) conference in Las Vegas. I was tempted mainly by the Business Architecture track as I was curious to learn more about the current state of affairs in that field. Here are some of my observations, and conclusions after attending the event.
- Confusion about Enterprise Architecture and its scope is further magnified by more confusion around Business Architecture. Various speakers made different pronouncements about the relationship between the two. Most saw Business Architecture as a component of Enterprise Architecture but some attempted to present Enterprise Architecture as being about IT and Business Architecture being about business. Another speaker suggested that Business Architecture overlaps with Enterprise Architecture but still is a distinct discipline that must “interface” with the Enterprise Architecture.
I agree with the majority that sees Business Architecture as a component of Enterprise Architecture. As to other views, well…, I find it fascinating that some people need to complicate things. Of course, Enterprise Architecture is about the enterprise, and the enterprise is about business, DUH! Need we say more? Presenting Business Architecture as something separate from Enterprise Architecture only increases confusion and…just wait, will lead to more frameworks. God knows we don’t need any more architecture frameworks. If you insist, then let’s fix the ones we have by giving them more business focus (…looking at you TOGAF…) instead of inventing new ones. In any case, enough with inventing more distinct “architectures”.
- Traditional roles of Business Analysts and Architects are evolving. Both roles are pushed to pay more attention to business value and business differentiation. Currently, in most organizations Business Analysts are relegated to requirement gatherers for IT projects. Their main focus is to translate requirements received from business into specific definition of IT deliverables and to perform validation of those requirements upon completion of implementation. There is very little going on there in regard to actual business analysis, not to mention Business Architecture. As Business Architecture rises to more prominence, Business Analysts must assume a role of true analysts and partner with Enterprise Architects in a comprehensive approach to Enterprise Architecture. At the same time Enterprise Architects are pushed to reach out to business and expand their role in the Business Architecture realm to make Enterprise Architecture more business-centric and thus more relevant to generating business value. This will likely lead to interesting dynamic with career paths. Both Business Analysts and Enterprise Architects are told that being Business Architects is in their future. However, Enterprise Architects also consider themselves well versed in technology, while Business Analysts not necessarily so. So where does this leave us? Will Enterprise Architects become generalists who rely on Business Architects, specialists, for the Business Architecture part of Enterprise Architecture? Or perhaps Enterprise Architecture will be pushed back to being again only about IT and Business Architects from Business Analyst ranks will direct Enterprise Architects how to shape the IT side of the enterprise?
- Business Capabilities emerge as the way to provide a common taxonomy that can bridge the gap between business and technology. Capabilities allow architects to focus on “what” rather than “how”. They provide an anchor to relate systems and their underlying technologies to the business context, which includes organization, people and processes. Furthermore, they help break the silos, ever prevalent in larger organizations, which often represent the obstacle to effective Enterprise Architecture.
Some can argue that capabilities and capability models have been around for a while and there is nothing new here. For me, the new thing was the evidence that companies start registering real successes with capability approach to Enterprise Architecture. It seems that capability models are finally taking off, coincidentally at the time when Enterprise Architecture, after some soul-searching, is beginning to focus on business value.
Overall, BBC was an interesting conference. Not great, just good. I found that too many speakers were contradicting each other, but truth be told they were simply expressing their own opinions and there is nothing wrong with that. I suspect that the conference was of most value to Business Analysts especially with several BA-oriented tracks. Business Architecture track was messy but it is probably due to the fact that most of us still try to wrap our minds around how it fits with everything else. I will consider attending next year, if only to watch the further evolution of the Business Architecture concepts.
More discussion on EA certifications …http://weblog.tetradian.com/2013/10/30/and-more-on-ea-certification/
Interesting observation published by Forbes: “CIOs And Cloud Computing: How IT Can Get Back In The Driver’s Seat“. While the article appears to apply to management of infrastructure in the world of cloud computing, it is symptomatic of a larger trend.
We have heard of the looming demise of IT for some time now. It started with outsourcing and globalization and intensified with the advent of cloud computing. The trend of “lost love” between Business and IT and illustrated in this article is not uncommon. I think it stems from factors like these:
- Business sees IT as an inhibitor rather than enabler of achieving business goals faster. The technical debt accumulated over the years starts to demand the interest payments. Delivery takes longer because complexity was not dealt with on ongoing basis. Desperate IT departments try to please the Business and they cut corners, leading to more technical debt. The vicious circle continues.
- Business sees IT as cost, which ever increases without generating more value. It’s like dealing with a cable TV company. The bill gets bigger every six months but the programming remains the same or gets worse.
- Business believes they can do IT themselves. Why wouldn’t they? Anyone can build a web site (okay, okay, maybe with the exception of the US government), anyone can buy cloud storage, anyone can write an app or commission writing one for pennies… Of course it is not that simple, but many on the Business side believe it is and droves of cloud service providers do their best to reinforce that belief.
Having IT relinquish some of its Implementation role in favor of the Advisory role is a good advice. Easier said than done though. It’s like with human relationships. After the love is gone it’s hard to get the flame going again. Is Business predisposed to seek advice from its IT Department, especially when there are so many advisers out there, who are eager to say “yes” to every request? Let’s hope so… This is where the Enterprise Architecture (EA) can lead. Stop talking to Business about interfaces, gigabits, servers, and tools. Instead, start talking about total cost of ownership, speed to market, competitive advantage, quality etc. In other words, speak the language of Business, not the language of IT. But more importantly, don’t just speak that language but start thinking that way too. Business really doesn’t care how IT is done anymore. They want us geeks to figure it out and not to bother them. For us however, it is a matter of survival. In order to serve Business better we must understand what it wants, or… fade into oblivion. We can only understand it if we think like business people.
So yes, again, it is all about the business. Adapt or prepare for extinction!
I love standards. There are so many to choose from!
But seriously, Survey of Architecture Frameworks compiles a list of so-called architecture frameworks. I noticed that it mixes actual “named” frameworks like TOGAF or DoDAF with languages/notations like ArchiMate and with what is probably better described as reference models. It’s okay. All of them have something to do with frameworks, albeit with varying levels of completeness.
It is a useful summary. It is also a sobering experience to see it all in one place and realize how many different approaches to architecture have been developed. It may be a testament to our quest for consistency and perhaps even obsession with frameworks. This reminds me a speaker’s statement from Gartner’s EA Summit 2013 – “…stop focusing on frameworks, focus on business value…”. We often forget why we DO architecture. Instead we put a lot of effort into implementation of architecture frameworks, striving for the cleanest, purest implementation. We argue whether ArchiMate Location element is appropriate to represent a department in an organization or whether “Customer” is better represented by a Business Role or a Business Actor. In the end, it doesn’t matter as long as we do it consistently.
Recently, I have been involved in several conversations about the Architect certifications. It is an interesting topic that comes up more and more as the number of people who call themselves Architects increases. It is only natural. After all, when every other person is an Architect, how do you tell the “good” one from the “average” one. One answer may be that only certified ones are “good”…or is it?
Before we get any further, I would like to recall the era when IT certifications became popular. They started as a way for people with limited experience in the field to move up in the ranks or get that dream job. As more and more people obtained the certifications those with real experience started feeling left out. It seemed that they were the only ones without the certification and the employers fanned the flames. So what is one to do? Get certified of course! In the end almost everyone with some skills got certified and the quest for differentiation had to start over. Oh what an opportunity for the certification vendors!
I believe that this game continues now with the Architect certifications. Some certifications are based purely on a study+exam model. Others attempt to add the component of experience assessed through personal interviews. In the end it all boils down to being able to understand number of architectural concepts and explain them to others. In other words, it’s largely about taxonomy and mechanics. It has little to do with the overall skills of an Architect.
In the spirit of full disclosure, I don’t hold any Architect certification and don’t plan on getting one unless the game described above forces me to do so. I do have a TOGAF certification obtained through my employer but that’s just a framework and one of many at that.
As you no doubt have guessed, I believe that the Architect certifications are worthless from the point of view of experienced Architects (can there be any other kind?). I think that anyone who practiced architecture, especially Enterprise Architecture, will agree that architecture can be seen as part science and part art. Often dealing with ambiguity, varying levels of abstraction, and uncertainty of long-term strategies. It requires a blend of vision and pragmatism and often relies on influence rather than authority. In fact, influence and compromise seems to be the name of the game, the modus operandi of successful Architects in the industry.
Can you certify one’s ability to influence? How about one’s ability to compromise? I don’t believe you can. Those are traits usually acquired through experience involving number of successes and mistakes in previous endeavors,… actually mostly through mistakes. I also believe that for some individuals those traits are more difficult to acquire than for others and it has nothing to do with them being less smart or less educated. It may have something to do with their personality types or maybe with their level of emotional intelligence (EQ). Can those be taught? Personality – NO. EQ – some believe that it can. In any case, I have trouble believing that Architect certifications can be useful as a measure of a skill of an Architect. But then again, maybe they are meant to signify something else. Maybe they are truly about taxonomy and mechanics and nothing else. Certification bodies seem to disagree, but then again, they do have a skin in the game. What do you think?