Archive for the ‘SOA’ Category

Want a successful API program? Think like a product manager.

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.

API Design: Compartments

I’ve been reviewing the FHIR (Fast Healthcare Interoperability Resources, http://www.hl7.org/fhir) specification and they have an interesting concept called a compartment.  Per the spec:

Each resource may belong to one or more logical compartments. A compartment is a logical grouping of resources which share a common property. Compartments have two principal roles:

  • Function as an access mechanism for finding a set of related resources quickly
  • Provide a definitional basis for applying access control to resources quickly

Let’s look at these statements one at a time. First, the component concept provides an access mechanism for finding related resources. One very common compartment in the specification is Patient. Other resources, like Condition, clearly have a relationship with Patient. So, if I want to find all conditions that a particular patient has, I actually have two paths for doing this.

  • GET /Patient/[id]/Condition
  • GET /Condition/?patient=[id]

[id] is the unique identifier in question. In this case, both of these requests should return the same thing.  But it’s not quite that simple.  Take another resource, Communication, which deals with secure messages sent as part of patient care.  In this case, we have:

  • GET /Patient/[id]/Communication
  • GET /Communication/?subject=[id]
  • GET /Communication/?sender=[id]
  • GET /Communication/?recipient=[id]

The first example returns any communication that involves the identified patient, whether to, from, or about.  The Communication specific inquiries only allow for inquiry by the attribute of the resource where a Patient identifier can be specified.  It just so happens that in the earlier case, the relationship within Condition is represented in a patient attribute.

Independent of whether you think this is a good or bad thing, this approach where there are two ways of getting to the same resources creates a decision point for the organization.  In a large enterprise, it’s entirely possible that the implementation for different resources may be handled by different teams.  With two (or more) different ways of doing this, it creates the risk of two (or more) different implementations.  It also creates a situation where a resource that can be a compartment needs to make sure that any time a new related resource is defined and implemented, they also need to make a modification to provide the compartment-based inquiry.  Once again, if this is a separate team, this means coordination. Anyone who’s worked in an enterprise knows that the more teams that get involved, the more challenging it becomes.  

These are not insurmountable difficulties by any stretch of the imagination.  In the case of the implementation, the compartment resource should simply act like a façade and make the appropriate calls to the resource (i.e. the implementation of the first URL in the examples above simply turns around and makes the call(s) below them to complete the inquiry, such as Patient calling Condition, or Patient calling Communication).  In the case of the coordination, that’s a matter of education and oversight to make sure it happens.  The greater risk is probably that too many things get defined as a sub-structure within the compartment resource, rather than defined as standalone resources.  This can be avoided by recognizing when a proposed resource has multiple compartments.  Take the following requests:

  • GET /Practitioner/[id]/Condition
  • GET /Condition?asserter=[id]

These inquiry would give me a collection of all conditions that a particular practitioner has ever dealt with.  If Condition  wasn’t a standalone resource, and instead a sub-structure within Patient, how would I go about forming this query?  It can be done, but it’s probably not going to look as simple as what is shown above. This is where I see the hidden strength of this compartment concept.  By recognizing where we can have multiple ways of organizing a particular collection of data and traversing relationships, we can then make good design decisions on what our resources should be.

Finally, FHIR also mentions that the compartment concept can also play a role in access control.  I haven’t dug into this one as much, but I think it may have some potential. The challenge lies with data that really has multiple owners.  As a patient, I may want to use an OAuth model to grant access to my health records to a mobile app I’ve downloaded. My doctor may want to do the same thing for an application he or she uses as part of my care.  The compartment approach could give independent access paths for each of these channels with their own policies.  Again, I need to give this one more thought, but I can definitely understand why HL7 put the bullet point about access control in their specification.

What are your thoughts about this notion of compartments?  Good thing? Bad thing?  Have you implemented a similar approach? What were the pros and cons of it?  Let’s start the discussion.

  

API Design Challenges: Competing Demands

Working inside an enterprise is constantly a challenge to balance competing demands and chart the best course forward.  Unfortunately, typical corporate IT culture is one where everything is ruled by project delivery metrics: on time and on budget.  Based on behaviors I’ve observed, this results in two common things:

  • Efforts to minimize the teams involved.  More teams means more coordination which creates risk to the schedule.  If you think about this, concepts like micro services and two-pizza teams all really have to do with the fact that it’s very hard to control the output of a team of 20 to 40 people. 
  • Where multiple teams must be involved, each team will argue to minimize the work that they need to do (they don’t want to be perceived as the ones who blew the budget).  I see it more frequently from the consuming side (e.g. user interface team saying, “Can’t you aggregate that data for me so I can just plop it in this table?”), but it can come from either side. Sometimes these questions will be masqueraded as “performance concerns”, even though in reality, we may just be shifting work (i.e. doing the exact same orchestrations, just out of different components that are owned by different teams). 

While I could write a whole blog (and probably have) about the impact of focusing on project metrics, that’s not the point of this post.  The fact is, these pressures exist and will continue to exist, so we need to have a plan on how to deal with them.  

On the effort to minimize the teams involved, the first thing you must realize is that the decisions you make are about the next project, not this project. So, if you are an API developer, what design decisions can you make on this project such that when the next project comes along, they can simply use your API rather than having you involved in their project to modify the API?  

To solve this problem, you need an API that is focused on breadth of use.  To understand the breadth of use, don’t look at the demand side (what your consumers ask for), look at the supply side (what you have to offer).  You can try to predict what consumers might need, but odds are you’ll be wrong.  If, instead, you look at your backing information stores, and come up with an API that makes all of that information available, there’s no use case that won’t be covered. If you do this, you now empower consumers to get at what they need without your involvement (at least from a development perspective).  

But what about performance?

This is where the competing demands can rear their ugly head, and it’s definitely more common to internal efforts?  Why? Because most of the people in IT have some knowledge of what’s going on behind the scenes.  They can ask the question, “why can’t I access your database directly?” because they know that database exists.  Ask them this question: “If this were an Internet-based API, would you be asking the API provider to let you run SQL against their backing database?” Of course not.  Having some insider knowledge can be a dangerous thing that can get us into traps where teams debate best performance versus good-enough performance.  Will removing service layers and allowing direct database access yield faster applications? Probably, but at what cost and risk? Are you willing to put the integrity of your data on the line to do this? Are you willing to create risk that some business change could result in a change to all of those systems now hitting that database?  There are more goals than just performance, and we need an approach that strikes the right balance on all goals, not just over-achieving on performance.  Remember, Internet-based APIs continue to power many innovative web applications with perfectly acceptable performance.  

The answer to the breadth-of-use versus performance debate, in my opinion, is to have a two-layer API strategy.  This is consistent with what James Higginbotham wrote about in this blog on the Front-End / Back-End API Design conflict.

Layer one is an API focused on breadth of use, where design is all about exposing as much information as possible in a high performing way.  Keep in mind that you should still need to define appropriate API boundaries, and the view of performance here is within your boundary of ownership.  Know what things influence the performance of your API, and give your consumers control over those decisions.  So, while your API may be capable of exposing all information from within your domain, that shouldn’t be the default behavior. If there’s a collection of information that is more expensive to retrieve, give the consumers the power to decide whether they want to incur that expense or not through a parameter in your API.  I like to call this layer the Business API, but you may prefer Internal API.
Layer two is an API focused on context-specific use.  I like to call this the Interaction API. While the most common use cases will be for a front-end, that’s not the only case where context comes into play.  Merely exposing something externally versus internally is a context change.  While you may want an API for all of your information internally, you’re not going to want to expose all of that information externally.  Additionally, aggregations across boundaries that can be done efficiently inside the firewall might not be so efficient from outside the firewall. The Interaction API is the place where optimizations geared toward more specific contexts are done, if they are needed.  In more cases than not, this layer probably is needed, but don’t view it as mandatory.  If what you have from your Business/Internal API is perfectly suitable for direct access by the end consumer, just use it.  

The other facet of this layer is that it puts ownership of logic in the right spot.  If it’s a particular front end that needs an API highly tailored toward their UI design that can be called out of the browser, let that team build it!  The particular combination of data is probably unique to their situation, so let them build it on top of the Business API that has been provided to them.  

 This two-layer approach to your API can hopefully help you avoid the debate around competing demands and instead get a solution that provides proper balance across both objectives.

    Dynamic Data in REST

    I had an interesting conversation with some colleagues around resource design that I thought would be helpful to share. 

    The starting point was a simple question:

    Should price generation be a HTTP POST or HTTP GET?

    There’s solid reasoning for either of them.  Let’s start with HTTP GET.

    From a consumer’s perspective, a GET probably seems very intuitive.  For how most people think about prices, it’s static information, so why wouldn’t it just be an attribute included on a GET of some other resource, like a Product, right? 

    For the purposes of this conversation, however, price is something that is computed at the time of the request.  In other words, some supporting static information exists (like list price), but the actual “price” charged to the customer is dependent on other contextual parameters.  Cases where this exists are the end price you pay at Amazon after taking into account shipping preferences, account status (e.g. Prime member?) or the price you pay when you buy a car.  These prices are determined on the fly and may only be good for a limited amount of time, because the contextual information is subject to change. Hopefully, you can also see that “price” is actually a complicated piece of information.

    Is HTTP POST beginning to sound better? Where this fits very well is that the “Price” is really a custom resource generated for that particular context.  The customer, even though they may use the phrase “get me a price,” is really saying, “generate me a quote.” At this point, we’re creating a new resource.  

    But there’s one more thing.  What if price calculation is expensive? If I make this a POST and generate this every time, won’t my costs go through the roof? Well, they don’t have to. There’s no reason that a subsequent POST with the same data can’t return a resource from cache  in this scenario.  In reality, you are probably updating the expiration date of the resource, so POST still makes sense. Furthermore, if you provide a unique ID for the calculated price resource, HTTP GET can be used to retrieve it again, it just shouldn’t update the expiration policy.

    So, out of this, I came up with the following guiding principles on deciding whether calculated/derived data should be its own resource:

    • Can the data stand on its own? That’s always a question for any resource.
    • Does the calculation require contextual data from the consumer to perform the calculation, or are all the parameters already part of the potential parent resource?
    • Is there value in keeping the calculated data around for some time to avoid re-calculation?

    Hopefully these guiding principles will help you out.  If you have other suggestions on factors that help this design decision, please feel free to share in comments or via your own blog post.

    Microservices Architecture versus SOA

    TechTarget has published another one of my “Ask the Expert” columns.  In this one, I offer up my thoughts on the differences between a Microservices Architecture and a SOA.  In a nutshell, I think the microservices trend has moved things in the right direction, a direction that many of the SOA pundits were espousing back in the mid-2000’s.  Regardless of what we were saying, however, there’s no denying that the reality of SOA back then was still more of service enabled architecture then service oriented architecture.  Give my thoughts a read, and feel free to post comments and questions in the discussion section over there. 

    Z Ride for Hope

    A break from my normal tech-related posts. 

    In September, I will participating for the second time in the Pedal the Cause bicycle ride in St. Louis.  This great event raises money for cancer research at St. Louis Children’s Hospital and the Siteman Cancer Center in St. Louis. 

    I filled out my rider profile in late June and dedicated my ride to Zac Epplin, my brother-in-law’s nephew.  In other words, he is part of my family.  Little did I know that on July 1, we would receive news that would make this ride much more personal for me.

    Zac was diagnosed in August 2013 after noticing a lump on his side during a soccer practice.  Zac’s team went on to win the state championship that year, and despite having just gone through several rounds of chemotherapy, Zac took the opening kickoff of their championship match, even though he could barely stand, let alone walk or run on the soccer field.  His teammates wanted him there. 

    Here’s a story the St. Louis Post-Dispatch ran on Zac during the tournament run.

    The community rallied behind Zac, holding several fund raising events to help out with his care. My brother-in-law told me that these events weren’t so much about the money, they were about hope.  Each time the community came together, it gave Zac hope. That hope gave Zac strength to keep fighting and to live his life beating cancer.  Stuart Scott of ESPN said, “you beat cancer by how you live while you live.”  That’s exactly what Zac did. 

    On July 1st, Zac’s battle with Ewing Sarcoma ended. He was only 19 years old. The Belleville News-Democrat published a great article about him with quotes from his soccer coach and teammates.

    So, I am asking all of you to share this post and consider donating to me on my ride, donating to some other cancer charity, or doing anything you can to give cancer patients hope.  If you share this, please use the hashtag #ZRideForHope.  I’d like nothing more than to see this go viral, so that his family knows that even though Zac’s battle is over, the message of hope will not stop and we will all do what we can to find a cure.

    You can donate to Pedal the Cause here. 100% of your donation goes to cancer research. 

    “I can do all things through Christ who strengthens me.” -Philippians 4:13, Zac’s “watch words” during his battle.

    The Age of The Micro-UI

    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.

    Project Governance Tips

    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

    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.

    New Compilation Book and Possible EA Book

    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.

    Clouds, Services, and the Path of Least Resistance

    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.

    The Enterprise Family

    While I’m sure the last thing we need is another analogy for enterprise architecture, a colleague of mine came up with one that really resonated with me. We were discussing principles, which many believe should represent the shared, unchanging values of the organization, in the context of enterprise architecture and governance. That’s when he came up with this analogy.

    Enterprise architects need to work with the enterprise as if it were a family. If you look at a family, especially one with kids, they have their moments, but over time, they all start to embody a set of shared values.

    Needless to say, I really liked this analogy. As a parent of three young children, I know exactly what he’s talking about. Now, this isn’t to say that enterprise architects are the parents of the organization, but we do need to be members of the family, more likely to be the wise elders, rather than the crazy uncle or creepy aunt.

    What really works with this is that families make mistakes. They’re in a constant state of learning and evolving. Sometimes, as a parent, our goal is to do the exact opposite of something our parents did. Sometimes we want to do exactly the same thing. Most importantly, there are a set of values that we want to install in our children. The easiest path to this is to be an example of those values. We get in trouble when as parents, we contradict those values. The kids will have their moments, because they’re still learning. The same holds true in an enterprise. Individual projects may contradict the values, but it needs to be seen as a learning opportunity rather than strictly a compliance and punishment issue. When the leaders contradict the values or the values are simply unclear, the entire organization is at risk of being dysfunctional.

    The role of enterprise architecture is one of ensuring that the enterprise is one big happy family. Sometimes we have to make a sacrifice for one member of the family. Johnny is heading off to college, so perhaps family vacations or other discretionary spending gets cut. While this is really of immediate benefit to Johnny, the decision embodies the family’s values of education. Sometimes Johnny’s little brother Tommy has to wear Johnny’s hand-me-downs. Sometimes we have projects that are of high priority and they get the focus. Other projects may have to reuse things created by other projects. Enterprise architecture needs to be the support for those decisions.

    Update: In the twitter conversation that has followed this post, the roles of family therapist and parental guidance have come up. This also came up in my original conversation with my colleague. In my opinion, parental guidance, at least regarding architecture, should be filled by EA and it must be an employee. An outside consultant will never embody the values of the organization, they aren’t a family member. A family therapist, on the other hand, can be provided by a consultant or by an employee. The therapist’s job isn’t to tell you what your values are, their job is to help you identify your own values, and help you identify things where your actions are inconsistent with those values. Normally, if the parents are doing their job, therapy isn’t needed. Parents set expectations up front, and keep an eye out for behaviors that don’t embody the values. If behaviors need correcting, they get corrected through a variety of techniques, whether a carrot or a stick.

    EA and Portfolio Management

    In her IT Business Edge blog titled Enterprise Architecture Paying off at Del Monte, Loraine Lawson writes:

    Enterprise architecture (EA) befuddles me. As far as I can ascertain, it began as an IT function, but at some point, it was decided that EA is bigger than IT and really needs to work with the business as a business function. … I’ve had my doubts about EA, even though I’ve written several times about how the discipline can reduce integration work.

    I thought I’d respond to these statements from the blog. First, regarding the thought that EA is bigger than IT. While some may argue that the original definition was always about more than IT, it’s certainly true that in practice, the focus was almost always within IT. The reason, however, that it needs to become more of a business function is that IT needs to be a business function, rather than being simply viewed as a support organization where things are thrown over the wall. This is also exactly the reason why Enterprise Architecture is a necessary function.

    In a pure support scenario, you do what the customer asks, period. You can try to sway the customer, but that’s a risky proposition. Everything is constrained by the definition of the project. In such a culture, decisions that may be beneficial when viewed from the perspective of multiple projects and multiple systems are extremely difficult to make, because they are outside of the control structure (the project) that governs all of the IT activities.

    Coming back to Enterprise Architecture, part of the reason it needs to be viewed as a business activity is to change the decision making process around how IT activities are defined. If this process doesn’t change, then IT can only make the best of the hand it has been dealt. Low level technology decisions, such as servers, operating systems, and programming languages, can be handled solely within IT, but as soon as you get into functionality and capabilities, it becomes far more difficult.

    In my opinion, the way to do this is through a practice of portfolio management, which I believe needs to be at the core of an enterprise architecture practice. Portfolio management isn’t a one time application rationalization effort, it’s an ongoing discipline that must be integrated into the decision making process for what activities (projects) take place. I’m not referring to project portfolio management, I’m referring to application portfolio management and technology portfolio management. If we do an effective job of this, we better understand the boundaries and dependencies between the capabilities that need to be provided. By better understanding these, the task of integration becomes easier, because it’s a forethought rather than an afterthought.

    It’s surprising that this focus on application and technology portfolio management is such a struggle. After all, concepts of portfolio management are well accepted in the financial world. It is a far more risky venture to just blindly purchase financial products that hot today, rather than taking a structured view of your entire investment portfolio and the goals you wish to achieve. But, alas, IT is a very project-driven culture in most organizations, and it is going to take time to change that. Many organizations have reached a breaking point where a one-time application rationalization effort is taken. If your organization is in this position, however, a one-time effort is only a short term fix. Business leaders must not only fix the current situation but also make the necessary changes to ensure it is does not happen again, and I believe a healthy enterprise architecture practice rooted in a disciple of portfolio management is one of those changes needed.

    Troux 2011: Leaders Perspective: Great Conductors

    Panel discussion. Panelists:
    Eric Christian, Director of Global Architecture Security at Cummins
    Sandy McCoy, Executive Director, Business Architecture, Kaiser Permanente
    Michael Balay, AVP, Technology & Operations, Enterprise Architecture, MetLife
    Moderator: George Paras

    Q: Inspiring an EA team is a challenging activity. If you had one bit of advice to an aspiring EA leader, what would it be?
    Sandy: There’s an outward leadership component and an inward leadership component. From the outward perspective, anyone on the team must be a leader. You operate at levels most people don’t. Emotional IQ important, and you have to be able to communicate both with a developer or project manager at one time and the CIO the next. From the inward perspective, your people must be empowered and encouraged. EA is a thankless job, you must know when your staff is having a bad day.
    Eric: We have a tremendous opportunity to add value. Focus on delivering it incrementally. Focus on delivering high value in a way that the business community can embrace.
    Michael: Leadership matters in every aspect of business, especially for the EA organization. Every staff member must be a leader. One of the most important things to do at each stage of transforming is to find leaders to partner with elsewhere in the organization.

    Q: As a leader, when you’re looking to incrementally grow your team, what skills do you look for?
    Michael: It’s about a team and having a balance of skills. I look for people with both operational and architecture skills.
    Sandy: We have a minimum of 15 years of experience, through various tracks within IT to have a variation in the skill set. When you start getting into business architecture, some business acumen is becoming more and more critical. Technology is just built into the business, we are part of the DNA.
    Eric: Strongest architects as of late have knowledge of the business. It’s easier to teach an architect to be an architect than to teach them the business in a particular industry.

    Q: Where do architects with business acumen come from?
    Eric: At Cummins, we have been looking at horizontal immersion programs. They take a horizontal assignment within the business and will hopefully come back. The same holds true for business staff to take a position within IT for a while.
    Michael: The balance is going to shift toward more business architects. I always want that business architect side by side with someone who understands the implementation, though. My bias is to find business people, match them up with someone from IT, and let them learn from each other.
    Sandy: One skill that I would add to the list is abstract thinking. If you have people that can really think abstractly and connect the dots, then their actual experience is not as critical. Not everyone has this ability.

    Q: What size team do you look for?
    Sandy: Our chief architect likes to re-organize every 6 months, but his boss tells him to stay stable for a year. You have to adjust to whatever is happening at the time. You need to have a bunch of utility players as well as some heavy hitters in particular areas.

    Q: What are the best practices to organization a team?
    Eric: Cummins, a couple of years ago had a very decentralized IT. Three years ago, IT was centralized, as where the architects. We have largely aligned along Technology Architecture, Solution Architecture, Enterprise Architecture.
    Architecture is an evolution, a maturity process. When you move toward the block and tackle approach, you start with fundamentals (doing well with infrastructure architecture), but as you move up you look at portfolio optimization, etc.
    Michael: There is no one model for EA. Almost by definition, it must be designed and tailored to the circumstances of the enterprise. Collaborate with other leaders. Enterprise Architecture must be responding to the strategic events of the company, and may not be able to steadily climb that maturity curve. Groups that do, may be too inwardly focused.
    Sandy:If you look at it as a role, rather than an organization, very rarely do we play the role of an Enterprise Architecture. As EA, we can play any of the roles, and we get pulled down into various levels of the architecture depending on the needs of the organization.

    Q: How do architects split their time between strategic and tactical work?
    Michael: A peer of mine worked on a very successful, strategic architecture for technology integration and services. This year, he’s continuing the effort, but driving down into the implementation of it. At different periods we need different skills.
    Michael: This is how things worked at Cummins a year ago. Each of the architects focused on quite a bit. They became spread to thin, weren’t focused on the right things, and the value was marginalized. We made a separation between solution architecture and enterprise architecture to create focus on both areas, and this yielded far more traction.
    Sandy: It depends how your mission statement is defined. We have 13 different divisions and they each have a different opinion on what we should be, plus the CIO has another opinion. Set some metrics on what you’d like to do.
    Michael: We’re struggling with refocusing. There are too many strategic things out there.
    Eric: One of the first things that was negotiated with my boss was the vision and mission. That became the contract. If business partners think something else, we come back to the contract.

    Q: How do you demonstrate the value of your EA program? How do you make the investment decision for a tool like Troux?
    Michael: We implemented Troux standards in 2-3 months. We were re-instantiating AIG standards. We didn’t have to reinvent the standards, but we did need to reach out to the international community. Traditionally, the review process came very late in the effort. We worked with the PMO to push up the visibility of the project to early in the process, especially so EA had visibility. If managers got involved early, 9 times out of 10, the went through the process very smoothly. We turned the traffic cop into a value proposition.
    Eric: We have seen value delivered in a body of analysis work that we have done. Most things have Oracle under the covers. We had our best year ever with an excellent growth trajectory. The value comes into play with trying to balance continued growth of new plants with a strategy for managing the instances of Oracle apps.

    Q: What should our audience be paying attention to?
    Sandy: Social networking and mobility. People who grew up with it, want and expect collaboration. On the mobility side, everyone wants a little “app” for a piece of the business. Information and data governance becomes much more critical because it is now exposed in places where you may not want it to be.
    Eric: Server, app, and desktop virtualization, mobile technology, and SaaS and cloud.
    Michael: Mobility, BYOD – bring your own device, Collaboration systems on a new scale, IaaS and virtualization. In the governance space, issue is that we’re already too slow for our customers.

    Troux 2011: Journey to the Business Side of Enterprise Architecture at USAA

    Speaker: Michael Pemberton, Enterprise Architect and USAA

    USAA has had an enterprise architecture practice on the technology side and is now establishing a business architecture practice.

    First point: Why did USAA take the journey? They realized that without a business-driven, integrated enterprise architecture, it would be like driving without a map.

    Their challenge was that they are trying to increase their revenue and the membership, but at the same time, reduce their operating ratio. They needed to reduce the complexity and operating friction within the organization.

    For them, being too close to the Enterprise Strategy team was a problem for their Enterprise Architecture team. It may seem counterintuitive, but there are some pressures to keep the strategy team “clean” while the Enterprise Architecture team needed to be out there working with the community.

    Models need to be designed to answer questions. The business doesn’t care about the components and representation in the model, they care about the answer to the question they asked. They aim to create visualizations for the enterprise.

    USAA Opportunities and Challenges:

    • No metamodel, no design!
    • Architect architecture
    • Business focused architecture
    • Visualizations, visualizations, visualizations
    • Roadmap capabilities
    • Killer curves: supply/demand

    They showed a visualization which was essentially a spoked wheel with member at the center of the universe. A layer out from the member was a set of capabilities, then another decomposition to the business level, and then finally a set of processes out in the business. They found the normal “box-in-box” capability view to be unwieldy for the number of capabilities they had.

    They also made a commitment to never come to the business with a single taxonomy again. They needed a single taxonomy to do their work, but the business needed to see the results in their own language and taxonomies. They create taxonomy alignment, but they don’t force a single taxonomy on the entire organization.

    Principles they use for their visualizations are:

    • Use graphics, not words (look up InfoGraphics)
    • Show context and meaning NOT context and conclusion
    • Enlightenment NOT training
    • if you ever show the business your model, you deserve whatever you get – and it won’t be pleasant
    • Quit telling executives they should use the tool!

    Ads

    Disclaimer
    This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.