This past week seems to be the week for the call to action for Enterprise Architects to start blogging. James McGovern called out that there should be more EA blogger's. More blogger's came into the fold such as Brandon Satrom who would like to see more on how EA's address some of the latest IT trends such as: S+S, user experience, OBA, ECM and more. While Todd Biske chimes in on the outlines some of the challenges Corporate Blogger's face. A fellow Microsoft blogger Nick Malik whom is an Enterprise Architect for MS always writes about interesting topics around SOA and EA.
Overall it looks like I picked a good time to start blogging about my EA experiences. Beware, this could be a long post...
Over the past year here at Microsoft I have seen that there is a substantial need from the IT community for EA guidance. This derives not only from what I've seen in the blogosphere but what I hear from both customers and events in which I present. With my role at Microsoft I have had the privilege of speaking to a great deal of system integrators, independent software vendors and financial services executives at Microsoft Executive Briefings or as we call them EBC's (everything has to be an acronym, huh...). Through these I talk to a load of CxO's, chief architects and senior technologists. Most times when I chat with senior level IT decision makers it's less about the technology and more about the "Business of EA".
So what does the Business of EA mean? Well it's more about how an EA organization operates such as: how it engages with the community, how it obtains community support/trust and how it is measured.
There are a set of common questions that I hear from fellow EA's and CxO's:
- What is the right level of governance?
- How do we overcome organizational barriers?
- How do we become change agents?
- What are the proven tools to help me in my efforts?
- What are some metrics in which we can demonstrate our value?
It's less about what is the right SOA or ESB, rather how do we get our "shop in order" so we can execute on these technology strategies. Personally I believe that the technology is easy to solve, however the softer skills are much harder for IT folks in general. The technology part of EA (i.e., Solution Architecture) is a challenge but is often overshadowed by getting EA off the ground and operating efficiently. This isn't just the case for immature EA organizations it is true for more mature EA organizations. Doing the right thing often means different activities as an organization matures.
For example, processes that were defined when an EA first started may have less stringent guidelines, intentional gaps in process and light governance. Whereas more mature EA organizations have adapted over time to their unique business drivers and specific organizational cultures. Additionally these may differ from business to business. Manufacturing EA organizations are more interested in creating agility whereas a Financial Services EA is more concerned with risk mitigation in their policies and architecture. When we talk about the business of EA there are many factors most of all.... the business.
Since the rational of this post was to highlight my agreement for the EA calling of arms I do want to comment on what some others have said about this topic. I really liked Todd Biske's post in which he talked about the fact that there are not many corporate IT blogger's. See below:
As James McGovern has lamented in the past, and Brandon Satrom recently, there really aren’t a lot of enterprise architects working in typical corporate IT blogging. By typical corporate IT, I mean at companies whose primary business is not technology. I don’t know if this carries over to other roles within IT, but I suspect it does. So, is this is a bad thing? A good thing? Some companies may have formal policies regarding blogging, some may not. It can be a complicated issue, however, I do think that there is one basic factor that comes into play, and that is trust. For the purpose of this conversation, I’m going to restrict it to where people are blogging about the domain in which they work. So, if you’re an enterprise architect, this is relevant if you want to blog about enterprise architecture.
I have bolded the questions Todd asks about EA's blogging. I think if corporate EA's start blogging about their experiences that it would be a great contribution to the overall understanding of the EA practice. The information and lessons learned could dramatically help folks that are struggling with this in their businesses. I encourage you! Obviously there are IP and competitive forces at play when you blog, but I'm sure you EA's know better. :)
As for James McGovern, I think he had a great idea about EA's in the federal government.
My current thinking says that we should direct this call to action directly at the respective Chief Architects within the Federal Government...
And there is Brandon Satrom who has some very good statements/questions on EA and Solution Architecture.
1) What are some proven methods around iterative EA? We’ve all heard the chant of “Future State-Current State-Gap Analysis-Migration Plan” enough to have it embedded in our souls, but how do we leverage these good ideas in a way that doesn’t relegate EA to functioning as a team of Binder Boys?
On this one, I am a strong proponent of using EA Meta-Data Repositories. I will post about my thoughts in greater detail later. My last role as an EA at a large financial services company I lead our repository initiative which was more than a catalog but a living breathing entity that united our our architecture strategy (Transition State Architecture and Future State Architectures) with Current State. With this base data we linked in other aspects such as Risk Management, Incident Management, Project Management, Portfolio Management and Configuration Management. We had most of it complete before I left and was essential to not making us into, what Brandon says: "Binder Boys".
2) Folks like Simon Guest with Microsoft (and many others), have started to collaborate with the User Experience community (The likes of Lou Rosenfeld, Peter Moreville, Jesse James Garret) for more interplay between Architecture and UX. Is this part of a bigger trend of moving away from EA as process and into EA “for the people?” I, for one, would love to see that happen, but what does that mean for the process- and framework-heavy aspects of traditional EA (I’m looking at you mister Zachman)?
Simon is great, I think he is doing some great stuff around UX. He has really started this whole movement here at Microsoft. And I'm not saying this because he is on my team or that he sits a few doors down... :) Simon is onto something here, as EA's we need to think of the business and the user is what really enables the business. With that thinking we need to be very concerned about the UX aspects of our solutions. And I do not mean if it's pretty or not but if it increases value to my business users.
I do not think this means a heaver framework, just changes to how we approach UX and information architecture. Yes I said it, information architecture, which we are really lacking in right now.
3) How does well-run EA best serve an organization first instead of worrying about controlling its decisions? On that note, how does well-run EA best serve its stakeholders first?
This one is a loaded question. Very simply I believe that developing a set of principles, policies and standards with your stakeholders gives you the structure necessary for both alignment and support by your stakeholders. This buy-in is how you keep focused on what really matters for the organization.
4) Is Microsoft on to something with this OBA thing? For that matter, are we really there with Composite Applications? Personally, I see this very idea as an evolution of Enterprise Architectures which serve the user by creating naturally productive applications, but what do others think?
So I have been doing a whole lot of ground work explaining what OBA's are and how to use them in the industry space this area for the past year. I was also very fortunate to have Mary Jo Foley of ZDNet comment on my blog saying it is a must see for all things OBA. I recently developed an Office Business Application (OBA) for the financial services industry that was built on an SOA architecture. I classify it as an Enterprise OBA. I agree with Brandon on this one as well. I see OBA's as the face of SOA. This bridges so many architecture concepts together such as UX and SOA (SaaS, S+S, Composite Applications). I have written some posts about this, check them out:
- OBA's Deliver SOA to the People
- OBA as a SaaS
- My EMEA OBA Road Show Recap
- Unstructured Data, the Achilles Heel of SOA
- MSDN Webcast: Office Business Applications
- Integration: Extending OBA's | Message Bus and OBA | OBA's and Industry Standards
- Mobile Business Patterns and OBA
If you want more you will have to just check out the blog... :)
5) How can an organization already in bed with a major software vendor more towards welcoming open source where it makes sense? What experiences have others had in this realm?
I think that Dave Linthicum makes some great points on the "big stack vendors" and the challenges associated.
6) Is ECM mature enough to be of strategic value to most organizations, or does the visible lack of standards and market volatility mean that we aren’t there yet?
ECM is crucial to most organizations especially the ones highly regulated such as: Financial Services, Healthcare and Government.
7) Is it okay to have a list of random EA questions and not ask any about SOA?… crap.
LOL... Brandon, your in the EA dog house now.
Tags: Enterprise Architecture Information Architecture OBA SOA SaaS S+S BI Solution Architecture
