Todd Biske: Outside the Box

Archive for the ‘IT’ Category

Kin Lane, the API Evangelist, had a really good post on maturing an API program, with the not-so-brief title of “I Have An API Deployed, And A Base Presence Established, What Can I Do To Help Me Get The Word Out?” You should definitely go read that because there’s some really good advice there.

What was very clear to me is much of what Kin and others talk about is essentially turning your API into a product and applying the discipline of product management. Set goals, identify your prospects, create marketing material, highlight the success of your customers, understand your competitors, provide good support, etc. I think it’s important for the technical audience to understand that these concepts aren’t new, even though they might be new to the technical crowd. As I know from my own experience, we technologists will flock to new technology just because it’s a shiny new thing to try out.  Unfortunately, that doesn’t make for a good product strategy.  Just as a blog of mine a long time ago on communications suggested bringing a communications expert onto your IT team, it’s also a good idea to have someone with product management experience work with you on your API program efforts.

The one thing in Kin’s post that I had a slight disagreement with was his section on goals.  While his goals were valid, these are really secondary goals to what is absolutely the number one goal: revenue.  Now, I’ve read enough of his other posts that I know he gets this, but I don’t think it can be emphasized enough.  I began my career in development and have always been on the IT side of the house, and for many, many reasons that I won’t go into in this post, too many people in IT really don’t understand the revenue models of their companies.  So, if you don’t understand how your API program will impact revenue, go back and figure it out.  You may be able to charge directly for API use and fund your own operations. It may be less direct revenue, such as how Walgreens’ photo APIs eventually result in revenue through in-store photo printing, rather than a fee for API use. Growth in new users might be great, but if there isn’t a revenue model, it will eventually become a cost sink.  One only needs to look at the number of press releases about public APIs being shut down to understand the importance of this.

All in all, Kin’s post is really, really good.  It calls out a number of specific things to do when your product is an API, so follow these things but also complement your efforts with some general purpose product management knowledge and you’ll be in a position to make good decisions.

In this article from the Wall Street Journal, author Christopher Mims quotes mobile analytics company Flurry’s data that 86% of our time on mobile devices are spent in apps, and just 14% is spent on the web. While Christopher’s article laments that this is the “death of the web”, I’d like to put a different spin on this. We are now entering the age of what I call the “micro-UI”.

The micro-UI represents a shift toward very targeted user experiences focused on a much smaller set of capabilities. A phrase I’ve used is that we are now bringing the work to the user, rather than bringing the user to the work. It used to be that you only had access to a screen when you were in the den of your house with the desk with the built-in cabinet for your “tower” (why do they still sell those?) with a wired connection to your dialup modem, or your computer on your desk at work. Clearly, that’s no longer the case with smart phones, tablets, appliances, your car, and many more things with the capability to dynamically interact with you. I just saw rumors today about the screen resolution of the new Apple Watch, and I think it has higher resolution than my original Palm Pilot back in the late 90’s. On top of that, there are plenty of additional devices that can indirectly interact through low power bluetooth or other tethering techniques.

In this new era, the focus will be on efficiency. Why do I use an app on my phone instead of going to the mobile web site? Because it’s more efficient. Why do notifications now allow primitive actions without having to launch the app? Because it’s more efficient. It wouldn’t surprise me to even see notifications without the app in the future.

For example, how many of you have come home to the post-it on your door saying “FedEx was unable to deliver your package because a signature is required.” Wouldn’t it be great to get a notification on your phone instead that asks for approval before the driver leaves with your package in tow? But do you really want to have to install a FedEx app that you probably will never open? Why can’t we embed a lightweight UI in the notification message itself?

In the enterprise, there are more hurdles to overcome, but that should be no surprise. First, the enterprise is still filled with silos. If it were up to me, I would ban the use of the term “application” for anything other than referring to a user interface. Unfortunately, we’ve spent 30+ years buying “applications,” building silos around them, and dealing with the challenges it creates. If you haven’t already, you need to just put that aside and build everything from here on out with the expectation that it will participate in a highly connected, highly integrated world where trying to draw boundaries around them is a fruitless exercise. This means service-based architectures and context-launchable UIs (i.e. bring the user to the exact point in the user interface to accomplish the task at hand). Secondly, we need to find the right balance between corporate security and convenience. All of this era of connected devices rely on the open internet, but that doesn’t work very well with the closed intranet. Fortunately, I’m an optimist, so I’m confident that we’ll find a way through this. There are simply too many productivity gains possible for it not to happen.

I believe all of this is a good thing. I think this will lead to new and better user experiences, which is really what’s most important. Unlike Christopher’s article, I don’t see this as the death of the web, as without the web as the backing store for all of this information, none of this would be possible. It is a reduction in the use of a browser-based UI, and he’s correct that there are some good things about the web (e.g. linking) that need to be adapted (app linking and switching) to the mobile ecosystem. On the other hand, however, this increased connectivity present opportunities for higher productivity. Apple (e.g. Continuity), Google, Microsoft, and others are all over this.

My latest article for SearchSOA has just went live. It gives a series of tips for making project governance more efficient. You can read it here.

Think enterprise first. Such a simple statement, but yet it is so difficult to do. Admittedly, I am an enterprise architect, so it’s my job to think about the enterprise. In reality, it’s not just my job. If you are an employee, it’s your job, too.

Why am I bringing this up? I believe that having a simple, clear statement that embodies the change that we’re looking for is critical for making that change occur. so, when I sat back and thought about my experiences over the years and tried to think of a general, common problem that needs to change, what became clear was the very project-centric culture of most IT organizations.

Projects are necessary to ensure that delivery occurs, but let’s face it, have you ever been on a project where scope was the least flexible thing? From day one, schedule and resources are always less flexible than scope. As a result, we have an IT culture that is obsessed with on-time, on-budget delivery, that will always sacrifice scope.

While schedule and resources will always wind up being the least flexible thing by the end of the project, it shouldn’t begin that way. The change that must occur is to start out thinking “enterprise first.” The simplest example I can think of this is in service development. What’s the behavior in your organization? Do teams build “their” application and only create services where a clear opportunity for reuse exists (or when a governance team forces them to), or do your teams define their projects as services first (regardless of any known opportunities for reuse) and then add in whatever application-specific stuff is necessary. The latter is an enterprise-first thinking, the former is an example of project-first thinking.

The argument you may have is, “isn’t this going to result in bloated , over-engineered solutions?” It shouldn’t. Making something a service doesn’t require surveying the enterprise for requirements. it means we place the proper ownership and management around that service so that it is positioned for change. We can only design to the knowledge that we have based on past experience and known requirements. We can’t predict what changes will come, we can only make sure we are properly prepared for that change. project-first thinking doesn’t do that, enterprise-first thinking does. Think enterprise first.

While I have not yet embarked on writing another book, I have been published in a second book. The publisher of my book on SOA Governance, Packt Publishing, has released their first compendium title called, “Do more with SOA Integration: Best of Packt.” It features content from several of their SOA books and authors, including some from my book on SOA Governance. If you’re looking for a book that covers a more broader perspective on SOA, but has some great content on SOA Governance as a bonus, check it out.

On a related note, I’ve been toying with the idea of authoring another book, this time on Enterprise Architecture. There are certainly EA books on the market, so I’m interested in whether all of you think there are some gaps in the books available. If I did embark on this project, my goal would be similar to my goal on my SOA Governance book: keep it easily consumable, yet practical, pragmatic, and valuable. That’s part of the reason that I chose the management fable style for SOA Governance, as a story is easier to read than a reference manual. If I can find a suitable story around EA, I may choose the same approach. Please send me your thoughts either by commenting on this post, or via email or LinkedIn message. Thanks for your input.

I saw a tweet today, and while I don’t remember it exactly, it went something like this: “You must be successful with SOA to be successful with the cloud.” My first thought was to write up a blog about the differences between infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS) and how they each relate to SOA until I realized that I wrote exactly that article a while ago as part of my “Ask the Expert” column on SearchSOA.com. I encourage you to read that article, but I quickly thought of another angle on this that I wanted to present here.

What’s the first vendor that comes to mind when you hear the words “cloud computing”? I’m sure someone’s done a survey, but since I don’t work for a research and analysis firm, I can only give you my opinion. For me, it’s Amazon. For the most part, Amazon is an infrastructure as a service provider. So does your success in using Amazon for IaaS have anything to do with your success with SOA? Probably not, however, Amazon’s success at being an IaaS provider has everything to do with SOA.

I’ve blogged previously about the relationship between ITIL/ITSM and SOA, but they still come from very different backgrounds, ITIL/ITSM being from an IT Operations point of view, and SOA being from an application development point of view. Ask an ITIL practitioner about services and you’re likely to hear “service desk” and “tickets” but not so likely to hear “API” or “interface” (although the DevOps movement is certainly changing this). Ask a developer about services and you’re likely to hear “API,” “interface,” or “REST” and probably very unlikely to hear “service desk” or “tickets”. So, why then does Amazon’s IaaS offering, something that clearly aligns better with IT operations, have everything to do with SOA?

To use Amazon’s services, you don’t call the service desk and get a ticket filed. Instead, you invoke a service via an API. That’s SOA thinking. This was brought to light in the infamous rant by Steve Yegge. While there’s a lot in that rant, one nugget of information he shared about his time at Amazon was that Jeff Bezos issued a mandate declaring that all teams will henceforth expose their data and functionality through service interfaces. Sometimes it takes a mandate to make this type of thinking happen, but it’s hard to argue with the results. While some people will still say there’s a long way to go in supporting “enterprise” customers, how can anyone not call what they’ve done a success?

So, getting back to your organization and your success, if there’s one message I would hope you take away from this, it is to remove the barriers. There are reasons that service desks and ticketing systems exist, but the number one factor has to be about serving your customers. If those systems make it inefficient for your customers, they need to get fixed. In my book on SOA Governance, I stated that the best way to be successful is to make the desired path the path of least resistance. There is very little resistance to using the Amazon APIs. Can the same be said of your own services? Sometime we create barriers by the actions we fail to take. By not exposing functionality as a service because your application could just do it all internally, in-process, we create a barrier. Then, when someone else needs it, the path of least resistance winds up being to replicate data, write their own implementation, or anything other than what we’d really like to see. Do you need to be successful with SOA to be successful with the cloud? Not necessarily, but if your organization embraces services-thinking, I think you’ll be positioning for greater success than without it.

On the Forrester Enterprise Architecture Community site, Randy Heffner asked the question, “What should EA do for business agility?” In my two responses in the discussion, I emphasized that EA is all about decision support. Yes, you may create a future state roadmap, but what the organization winds up with is completely dependent on what projects the organization decides to execute, and then on how those efforts are executed. EA influences those decisions, but we’re not the ones making them.

So why is this post titled, “Deciding ‘Yes’ on EA”? In that same discussion, William El Kaim added the following:

Let me be real provocative, and state: EA is dead … It has been killed by architect themselves leaving in their ivory tower and their beautiful EA drawing tool that nobody uses and that contains outdated data when they are published.

You can read the rest of what William had to say on the Forrester site, but I don’t think it’s anything any of us practicing EA’s haven’t heard before. But there’s a very important point in William’s statement. If nobody uses what EA produces but EA themselves, that’s a big problem. Put simply, if we provide poor decision support, the organization will ultimately decide against EA.

Like most things in this world, there are far more ways to fail than there are to succeed. So what are some best practices for providing excellent decision support so that the organization will decide “yes” on EA?

1. Figure out who makes the decisions. Sounds simple, right? Not quite. I’d love to see a Forrester or Gartner survey on this one, but I’m willing to clarity and consistency on the decision making process is not a strength for most organizations. Regardless of the state of your decision making process, if you don’t have access to the people making the decisions, you have little to no chance of influencing them.
2. Figure out how they make their decisions. Note that I didn’t add, “and make them better.” Remember that they’re the one making the decisions, not you. Your role is to give them added information so that they can make the best decisions possible. In some cases, the whole reason for having the discussion may be so you can learn and incorporate that decision maker’s information into your guidance for other decision makers.
3. Make your information relevant to them. Don’t give them a bunch of models that are only meaningful to another EA. In the case of upward decisions, this usually means that the architecture implications have to have financial ties, or clearly alignment with business objectives. I’ve had success using capabilities in these discussions, and I think the current research would back that up. You must tailor your information to their needs. If they don’t understand it, it’s your problem, not theirs. They’re making the decision, not you.
4. Emphasize added insight, not oversight. This is very important for interactions with project teams. All too often, EA is positioned as the enforcer. Come before the review board and we shall assess your worthiness. I’m sorry, but a guy who spends 80% of his time writing code each day should be far more aware of the latest frameworks than the average EA. The role of the EA is bring enterprise and/or domain perspective to the effort. As soon as the project gets established, the project blinders go up, and it’s the job of EA to remove those blinders and add enterprise insight into the effort.
5. Don’t rely solely on artifacts, and where you must, make sure they are easily digestible. While many factors in an organization lead us toward email-based interactions of documents, try to have a face-to-face conversation about the guidance whenever possible. At a minimum, by walking someone through it, you at least knowing they’re actually reading some part of it. When you create the artifacts, get them to the point.
6. Be cautious about consulting models for EA.A consulting model for EA is great, right? When someone needs more information to make a decision, what do they do? They hire a consultant. So EA should be internal consultants, right? Well, not really. That may work in the short term, but it is a “I’m here when you need me” model, when you really want to always be a part of the process. Don’t turn down the consulting approach, as it can get your foot in the door, but make sure you turn it to something more systemic.

What other best practices (or worst practices) do you recommend in firmly establishing EA as a valuable resource in the decision making processes in the organization?

Every organization has one. For some, it can lead directly to a path of enlightenment. Others may use its rigid structure to create an impenetrable fortress of strength. For the unfortunate, it becomes an inescapable labyrinth of hopelessness. Yes, it’s the org chart.

Okay, let’s be fair, it’s actually not the chart that’s the real challenge, it’s the organizational structure. Any organizational structure creates boundaries, and those boundaries create opportunity for divergence, whether in strategy, opinions, processes, or just about anything else. The challenge is figuring out how to structure the organization to diverge where you need divergence, but to be consistent where you want consistency. It’s no surprise that organizational structure is considered by some to be part of the enterprise architecture. Just as we try to organize our technology portfolio in the best manner to achieve the desired business goals, we need to organize our human resources as well. More importantly, just as management may choose to reorganize its human resources as the business goals and operating context changes, the way we organize our technology portfolio needs to change as well.

The organizational structure poses a particular challenge for the practice of architecture, particularly when it comes to solution architecture. I’ve seen at least three different models for organizing the architecture practice. First, is the centralized model where all architects report up to a single Chief Architect or Director of Architecture. There may be some middle management in there, but there is always a solid line leading to the top. As you might guess, this usually leads to a high degree of consistency, but can have challenges in scaling to meet demand, retaining business domain knowledge, and of course, ensuring that the centralized resources actually get used by projects and avoiding “rogue architecture.” The overuse of the term “architect” in job titles these days makes this even more problematic, as senior or lead developers may now have the title of Java/.NET Architect. It may also create delays in decision making, because the solution delivery has one reporting structure, while the solution architecture has a different reporting structure. If there is a disagreement, these two management structures must come together to resolve the difference, or it must be escalated up the chain.

A second model is a separation of the Enterprise Architecture function from the Solution Architecture function. Enterprise Architects have a solid line to the Chief Architect/Director of Architecture, Solution Architects report through a different structure, perhaps having a dotted line back into the EA organization in a matrixed structure. Consistency becomes more of a challenge, because Solution Architects will likely receive more direction from their management structure than from the EA team. It also creates challenges for the EA function, because now the EA team is at risk of being completely disconnected from solution delivery. Even in the centralized model, the bulk of the input into the solution comes from the solution management side of things. Now, that push will be even stronger, with architectural management struggling to maintain a voice. That voice is sometimes mandated through an architectural review board, but if that’s the only time that architectural management has the solution architect’s ear, the effort is likely to struggle with EA being seen as an ivory tower, rather than a necessary contributor to solution success. I’ve seen this model more than either of the others, however.

The third model would be the completely decentralized model. In this case, there is still a practice of architecture in the organization, but it is completely distributed. Solution architects, and perhaps domain architects, are scattered throughout the organization. A virtual team may exist, and there may even be a Chief Architect/Director of Architecture, but the role may largely be one of information sharing and coordination, and not really about architecture management. What’s good is that there’s not much risk of being perceived as an ivory tower, but there is significant risk of poor architectural alignment. If the boundaries of diversification are based upon an assumption that business units do not share customers, what happens if the situation changes and they do? Even ignoring the potential for this situation, decisions on centralization versus a matrixed approach are likely made locally within each business unit.

So what model is right? First, a completely decentralized approach is really only suitable for companies with a completely diversified operating model (see this book if you don’t know what that means). So, it really comes down to centralized versus matrixed, and that will either be applied at the business unit level for a diversified company, or at the enterprise level for other operating models. Both centralized and matrixed can work, but there is a catch. I’ve used the term “architecture management” in this blog. As I wrote this, I kept thinking about parallels to project management and a PMO. I’ve seen centralized PMOs where all project managers report into a single organizational group, and I’ve seen decentralized PMOs where individual project managers report into lines of business while a core group of resources that look at things from a portfolio perspective report into a Director of Product Management. The catch is consistency. If each project manager did things their own way, it is going to be extremely difficult for anyone to manage things at a portfolio level. Without establishing some minimum level of consistency that produces the necessary metrics and information at the right times for portfolio level management to happen, you’re sunk. Fortunately, for project management, the need for this is a well accepted practice. No one wants to wait to find out that a project is $100M over budget until after it happens. If you have that consistency, you can make either model work.

In the case of architecture management, things are still maturing. The problem is that we are at risk of focusing solely on consistency, without properly understanding the outcome that consistency is supposed to create. While finding out that you’re $100M over budget after it’s been spent is well understood as a bad thing, is finding out that someone has built a component that already existed elsewhere in the company a bad thing? Not necessarily. Those decisions need to be made in the context of both the project’s goals and the enterprise’s goals to make that distinction. Pursuing enterprise consistency when there are only project goals involved in decision making puts you at risk of being perceived as an ivory tower. At the same time, it may be necessary to pursue some base level of consistency prior to establishing that enterprise context, otherwise the context may be perceived as irrelevant. This can happen when the practice of solution architecture really isn’t being practiced at all.

My final advice is this: a centralized path will definitely lead to the most consistency, but you have to be rock solid in your justification of the need for an enterprise viewpoint, because that centralized model creates management overhead, risk of resource availability, and the potential for conflicting direction. A decentralized model is at less risk of having resource availability issues, but makes consistency more difficult and is more prone to sacrificing enterprise direction for project delivery. Ultimately, it will come down to whether your organization has been successful with matrix management approaches or not. If it has, you should be able to make a decentralized approach work. If you’ve never been successful with matrix management, then a centralized approach will likely be necessary. Finally, if you go with a decentralized approach, but have very inconsistent architecture practices, I strongly recommend that you establish an architecture mentoring/facilitator practice. In this, members of the centralized EA team facilitate one or two day architectural workshops. This can ensure that things are done in a consistent manner, the voice of the enterprise is brought into the solution architecture process, but the risks associated with a completely centralized model are mitigated.

I’ve been doing some work recently on architecture principles and their associated implications. According to TOGAF 9’s documentation on architecture principles, implications “should highlight the requirements, both for the business and IT, for carrying out the principle – in terms of resources, costs, and activities/tasks. … The impact to the business and consequences of adopting a principle should be clearly stated.”

In the effort to define our implications, I’ve started to see two categories of implications emerge. The first is behavioral implications. These implications are functions or processes that the organization must adopt. The second is architecture/design implications. To illustrate this, use a very simple principle: standards-based. The statement for this principle merely states that all solutions must be compliant with company standards. A behavioral implications for this is that someone in the company must maintain a list of company standards. Another behavioral standard may be that the company must follow the work of standards organizations relevant to the business. An architecture/design implication would be that messaging interfaces must adhere to published company standards.

I’m finding that it may be worthwhile to explicitly define these categories in documenting the principles. One big reason is to avoid overemphasizing the architecture/design implications. It is very easy to strictly think of implications as the foundation for your assessment framework, but an assessment framework, in my experience, is typically associated with architecture and design reviews. It says nothing about reviewing the behavior of the organization, which all too frequently can be the greater challenge. For example, a reusable service may exist, but it doesn’t get used because the organization “supporting” it may see supporting other consumers as a secondary priority, at best. This isn’t a design issue, it’s a behavioral issue.

One additional thing I’m also considering is how to assess whether or not the thinking behind the implications is correct. If the rationale for a principle is that total cost of ownership will be lower, are we actually measuring whether this winds up being the case based upon our level of adherence to principles and their implications?

How would you categorize your implications? Does this two category breakdown make sense, or are there additional categories needed?

This presentation was given by Richard J. Reese, VP of Enterprise Architecture for Discover Financial Services.

He started by showing some of the Discover “Peggy” commercials (look them up on YouTube, they’re pretty funny) and emphasized that Discover is known for their cash back programs and their customer service.

EA resource allocation at Discover is 35% solution architecture, 24% on governance, standards and frameworks, 2% on innovation and research, 5% on IT strategy planning, and 28% on roadmaps and assessments. Rick recognizes that the emphasis on current projects is an issue. Their challenge is to move from project focus to a strategy focus, generate measurable business value, manage the federated architecture discipline, and change the perception of EA (it had been seen as a roadblock/police force).

Their approach was to build credibility through their IT metadata. They have collected data from a number of different sources throughout the enterprise, integrating it into their EA repository. They had to standardize application names, and worked with internal audit to make it happen. Out of this, they built a number of business models, including ones that mapped the IT metadata to key business capabilities. Business capabilities have short, terse descriptions and they map these to the application that provide them.

Another area for improvement was to streamline their ARB (architecture review board) process. They have a standing weekly meeting where they can tie a product name to an ARB approval number, and they worked with finance to make sure nothing was funded that did not have an ARB approval number. This echoes a previous speaker who encouraged us to follow the money. Make finance/procurement a friend of EA.

They also created an EA value log, capturing value created, costs avoided, and other traditional measures.

Lessons learned:

• Set an EA strategy with metric based goals
• Develop credibility through collecting facts
• Know what works in your culture
• Find sympathetic partners (e.g. Audit, Risk, Compliance)
• Invest incrementally
• Promote successes

Rob Koplowitz of Forrester recently posted, Why Tibbr Matters. He provided some examples of where an activity stream across a network like Tibbr could add value, and some examples where it couldn’t. I responded with a comment and I wanted to elaborate on my comments here.

Activity streams tied to your company that are available through tools like Chatter, Yammer, and Tibbr have potential for adding value, but there’s some big barriers that must be overcome. In my experience, I’ve used email, Sharepoint and other other internal portals, and Yammer inside of a corporate setting, and there’s two simple objectives that these tools should have, at a minimum:

1. Moving information from the privileged few to a broader audience.
2. Making new information available that previously wasn’t.

On the first item, a challenge that probably every organization has is getting the information to the right people. The information exists, but it only spreads through word of mouth or to people that the information holders think need to be aware of it. The twitter model is the right approach for addressing this, by allowing people to follow people or topics of interest (either via saved keyword searches or hashtags), rather than having to wait until it is explicitly sent to them. In order for this model to work, however, all information must be public. As soon as private, directed messages come into play, that information is now hidden. I don’t see this as the bigger of the two challenges, however, as at least the information exists, it’s just not getting everywhere it needs to go.

The second item is the greater challenge. If there is information that simply isn’t being communicated, there is no tool that is going to magically make that information appear. The more information sources you have participating in the network, the greater potential you have for getting value out of that network. Why does everyone join Facebook? It’s the network with the greatest participation, and therefore, the greatest potential value. There’s a catch-22 here, because you want participants to get value quickly, so they stay in the network, but once you get over the hurdle, the growth will come. So how do we do this?

In a corporate setting, the participants are not just your employees. The participants must include your systems. This is why Tibbr is potentially in a good spot. Tibco’s background is not in collaboration or social media, it is in system integration. Unfortunately, all of the web-based request/response systems over the past decade have gotten us away from the asynchronous, event-based system design of the past. Even SOA tends to imply a request-response paradigm in most people minds, meaning I have to know what to ask for in advance. Both our systems and our people need to expose items of interest without any preconceived notion of who might be interested. Yes, we need to be cautious about signal to noise ratio, but I don’t think that problem is any different than trying to manage redundancy in an application or service portfolio. As part of your deployment process, get a list of the events/messages that are available, categorize them, and manage them effectively. If the Twitterverse can quickly come up with accepted hashtags, why can’t we do the same inside our corporate worlds?

Since I’ve previously asked for this year to be the year of the event, let’s do so in a way that allows these events to feed into our internal activity streams and social networking tools, and start getting real value out of these technologies.

In this, my first blog post of 2011, I’d like to issue a challenge to the blogosphere to make 2011 the year of the event. There was no shortage of discussions about services in the 2000’s, let’s have the same type of focus and advances in event’s in the 2010’s.

How many of your systems are designed to issue event notifications to other systems when information is updated? In my own personal experience, this is not a common pattern. Instead, what I more frequently see is systems that always query a data source (even though it may be an expensive operation) because a change may have occurred, even though 99% of the time, the data hasn’t. Rather than optimizing the system to perform as well as possible for the majority of the requests by caching the information to optimize retrieval, the systems are designed to avoid showing stale data, which can have a significant performance impact when going back to the source(s) is an expensive operation.

With so much focus on web-based systems, many have settled into a request/response type of thinking, and haven’t embraced the nearly real-time world. I call it nearly real-time, because truly real-time is really an edge case. Yes, there are situations where real-time is really needed, but for most things, nearly real-time is good enough. In the request/response world, our thinking tends to be omni-directional. I need data from you, so I ask you for it, and you send me a response. If I don’t initiate the conversation, I hear nothing from you.

This thinking needs to broaden to where a dependency means that information exchanges are initiated in both directions. When the data is updated, an event is published, and dependent systems can choose to perform actions. In this model, a dependent system could keep an optimized copy of the information it needs, and create update processes based upon the receipt of the event. This could save lots of unnecessary communication and improve the performance of the systems.

This isn’t anything new. Scalable business systems in the pre-web days leveraged asynchronous communication extensively. User interface frameworks leveraged event-based communication extensively. It should be commonplace by now to look at a solution and inquire about the services it exposes and uses, but is it commonplace to ask about the events it creates or needs?

Unfortunately, there is still a big hurdle. There is no standard channel for publishing and receiving events. We have enterprise messaging systems, but access to those systems isn’t normally a part of the standard framework for an application. We need something incredibly simple, using tools that are readily available in big enterprise platforms as well as emerging development languages. Why can’t a system simply “follow” another system and tap into the event stream looking for appropriately tagged messages? Yes, there are delivery concerns in many situations, but don’t let a need for guaranteed delivery so overburden the ability to get on the bus that designers just forsake an event-based model completely. I’d much rather see a solution embrace events and do something different like using a Twitter-like system (or even Twitter itself, complete with its availability challenges) for event broadcast and reception, than to continue down the path of unnecessary queries back to a master and nightly jobs that push data around. Let’s make 2011 the year that kick-started the event based movement in our solutions.

According to ZDNet’s Joe McKendrick’s coverage of the recent Gartner Application Architecture, Development, and Integration summit, SOA governance and siloed thinking is top of mind.

If this really is the case, how do we make our governance efforts more effective? The more I think about this, the more I come back to a recent post of mine from earlier this year: “Want Successful Enterprise Architecture? Define ‘Enterprise’ First.” I’m convinced that this is a critical step for any effort that tries to go beyond a project-level scope, SOA initiatives included. If you don’t provide a structure that says what things will be implemented and managed at an enterprise level, versus a domain level or project/team level, anything with the term “enterprise” will be a struggle.

Too often, the approach to governance is concerned with establishing oversight, not establishing outcomes that are rooted in an agreed upon definition of what will be managed at an enterprise level, a domain level, and at the project level. Does it really help to set a standard that a particular coding library must be used when there is no central team that manages the library, no centralized support team, and no stated strategy for developer portability across projects? No, it just gets people up in arms and accusations of EA or the governance team being an ivory tower that sets arbitrary standards.

In my book, I defined governance as the combination of people, policies, and processes that are put in place to ensure the organization achieves one or more desired behaviors and outcomes. It’s not there to simply have a check mark to that says, “I went through a review.” In the absence of clear desired behaviors and outcomes, that’s what you will have. There is no reason to have an enterprise architecture team review a project if there are no things that are managed (or desired to be managed) at an enterprise level. You need to have some idea of what those things are up front, along with a mechanism for quickly making decisions on new candidates for enterprise items. The project team must know that this analysis will be done, and that it is a necessary part of achieving the company’s strategic goals, which they should be well aware of. Lack of communication of these goals can be just as detrimental and is often a symptom of lack of agreement on enterprise goals or inadequately specified goals: “Sure, we need to cut our IT costs by sharing more systems. I’m all for it as long as they’re not mine.” Someone needs to define exactly what the target areas are.

To be successful, we must define the desired outcome first. We must clearly establish the list of things that must be managed at an enterprise level, a divisional level, or left to the discretion of individual projects/teams. In fact, it’s even more fundamental than this. We can’t even know what success is without doing this step. There were no shortage of companies in the past that stated they were adopting SOA, my question to them would be, “How do you know when you’ve been successful?” Simply having a bunch of services doesn’t mean you’ve adopted SOA, it has to be the right services. Too often, enterprise architecture teams are positioned for failure because this fundamental step has not happened. Before you task your enterprise architecture team with reviewing all projects, make sure you’ve defined what enterprise is. If you haven’t, task your enterprise architecture team with doing the analysis of what’s out there and coming up with some recommendations. Then, your governance program will actually have a desired outcome to use in their reviews.

I recently completed reading the book Troux Enterprise Architecture Solutions by Richard Reese. First, the disclosure: this book was provided to me by Packt Publishing for the explicit purpose of this review. In addition, Packt is also the publisher of my own book, SOA Governance. I have no relationship with Troux, however, I have had discussions with various sales staff from Troux over the course of my career. This post is a review of the book, not a review of Troux.

First off, the book is well-written. I never felt like I was slogging through inordinate amounts of text, the chapters were of an appropriate length, and the level of detail was consistent throughout the book. Not including the index, it’s just shy of 200 pages and was a very easy read.

As a book on Enterprise Architecture, I found chapters 1-5 and 11 to be the most valuable. These chapters focused on managing the IT portfolio, creating strategic alignment, optimizing the application portfolio, IT governance, managing the EA practice (roles & responsibilities), and generating value. If you are new to Enterprise Architecture and need some ideas on how an EA program can contribute value to your organization, read these chapters. Chapters 6-10 are more focused on describing aspects of the Troux platform, with lesser emphasis on the practice of Enterprise Architecture. These chapters discuss architecture modeling, transformation platform, metadata management, visualization, and TOGAF support. Finally, chapter 12 is a summary, but I have to call out that it had one odd section on EA and cloud computing. This seemed out of place, and frankly, unnecessary. It felt like someone said, “Cloud Computing is the hot topic today, you have to say something about it.”

In terms of covering the Troux platform, it is important to know that this is not a how-to book. It is an overview of the platform. The right audience for this book are people that are looking to establish or mature their EA program and people that are considering investing in EA or Strategic IT Planning technology. For a $40 investment, this book provides excellent insight into the Troux platform. When you consider the time and money spent in vendor selections, this book is a very small price to pay to give you a great idea of what Troux can do, without any sales pressure. Having participated in many different product evaluations over the course of my career, I’m surprised more companies have not taken the approach of writing a very easy to read book targeted at the people that are considering asking for budget dollars or performing evaluations. Getting back to the content of the chapters, from my perspective, I preferred the more EA practice focused chapters with mentions of how Troux fits in over the chapters that were more focused on the platform (6-11), but my area of interest is the practice of EA. For someone who has concerns about whether Troux itself will work with the architecture methodology or be able to share information with other systems, such as a CMS/CMDB, these chapters cover those topics. It is good that the author covered both areas, as not all readers will have the same objectives for the book.

Summing it up, would I recommend this book? Yes. While the target audience is a bit narrow, for that audience, I think the book is quite valuable. Its appeal is not limited to people solely interested in the the Troux platform or EA technologies, as I think it has value for people interested in either establishing or maturing their EA practice. Some of the other books I’ve read on EA tend to be very academic in nature, this book doesn’t fall into that category. Instead, the coverage on the practice of EA was very pragmatic, even if though it does portray a very mature, structured IT organization. If you’re trying to determine whether EA or strategic IT planning technology is right for your organization, I would definitely read this book before jumping into vendor discussions, evaluations, and POCs.

There was a great discussion on Twitter today regarding influence, mandates, and leadership. My interest started with a tweet from Chris Venable, directed at Burton Group/Gartner EA analyst, Mike Rollings:

If EA is so important, why must it do everything through influence? No one ever says that to the CIO…

I thought this was a great question, and after retweeting it, a debate ensued around influence, mandates, and leadership among myself, Mike, Philip Allega of Gartner, Chris Lockhart, and others. In a nutshell, the question is this: Is it possible to be an effective leader without mandates?

My gut answer to this is yes, and I even feel that issuing mandates puts you at risk of being ineffective. As I dug into this, however, I realized that it’s not about the term mandate, it’s about the approach you take to providing leadership. Why is that the case? Look at the definitions for mandate, direction, and guidance, courtesy of thefreedictionary.com.

Mandate: An authoritative command or instruction
Direction: An authoritative indication; an order or command
Guidance: Leadership, instruction, or direction

I don’t see a big difference, do you? Yet, I’m sure we’d all agree that those terms are perceived very differently. Would you rather work for a manager that gave you direction or issued you a mandate? According to the dictionary, it’s really one and the same. Now look at influence:

Influence: A power affecting a person, thing, or course of events, especially one that operates without any direct or apparent effort.

The definition for influence actually mentions the word “power” which could be perceived as a negative, but more importantly, it goes on to state that we use the term more frequently when the power is imperceptible. This is where the difference lies. If mandate and direction mean the same thing, the real difference is when the leader can give that direction and influence the outcomes of the company without pushing so hard that it is perceived as something out of the ordinary at the time it happens.

An arbitrary mandate is like a shove in the back. It will be noticed, and it will be perceived in a negative manner. A justified mandate can be equally jarring, but can be acceptable in the short term. “I shoved you to the side so you wouldn’t walk into the huge pit of snakes that was in front of you because you were looking elsewhere.” The problem with both of these is that they’re “in the nick of time” decisions, and have to be jarring because there’s no other choice. The natural question then, is how did we get here in the first place?

This is where true leadership comes into play. Leadership is about setting people up to be successful from the beginning. That doesn’t mean that course corrections might be needed, but you set expectations early. How many of you have had an architecture review, or even worse, a performance review, where you were criticized for something you didn’t even know was expected? That’s bad leadership. Set the expectations and give people a chance to be successful. In setting the expectations, it must first be about the desired effect (note that nearly all the definitions for influence include either the word affect or effect) and not about the means. If it’s solely about the means, it becomes an arbitrary mandate. For example, “The desired effect is that our IT operational costs go down by 10%. We’re going to do that by consolidating redundant systems for X, Y, and Z.” rather than simply saying, “Everyone’s going to have to use system X from now on.” By not disclosing the desired effect, people will resist the change. By leading with the desired effect, you can also create an opportunity for people to come forward with alternatives. Where the effect is hidden, decisions become arbitrary or personality-driven, rather than outcome driven (see this post).

In a nutshell, set the desired outcome, establish a direction to achieve it, make course corrections as needed with an imperceptible gentle nudge so that it won’t be perceived as a mandate. That’s an example of influence, and that’s an example of leadership.