Enterprise Initiatives

When I first stumbled upon Twitter a year ago, I just couldn't understand the attraction behind it. I did notice that millions of people were using it so I decided to pay attention to it. Experience tells me that anytime a million people start to use a tool on the web, somebody is eventually going to figure out how to use this in business to make money. After reading about Twitter for a while I still wasn't finding the need to Tweet. But unlike many people my age and generation, I did not brush it off as a nonsense tool. Instead I created an account and started using it. I just started following a couple of blogger friends of mine and found that this tool has some potential. The value of Twitter increases dramatically as more people are added to your network, both followers and followees. I also stumbled across an article called Twitter Tools, Tweaks, and Theories which has opened my eyes to more possibilities. I won't repeat the article here but there are many valid uses for Twitter beyond discussing what you had for breakfast. This article called Why Twitter is Significant also provides a good perspective on why this is more then a fad and a toy for the younger generation.

My goal is to have a 100 followers and to follow a 100 people. Once I get there I will post a Twitter lessons learned. I have added a Twitter Widget to my blogs for you all to follow. Check it out. I added a funny Tweet today about a bad security practice I witnessed today.

Reading about SOA is like watching a tennis match. One day it is the answer to everyone's prayers, the next day it is too complex and the business doesn't want it. The arguments go back and forth day in and day out. I can tell you that SOA done right can totally transform a company. There is no one way to approach it but I will share the method that we used.

Step one - Research the living daylights out of SOA. Read blogs, go to conferences, interview companies who have had success, read books, talk to consultants who have been through many implementations.


Step two - Find a business problem to solve. What is a major pain point for the business? What key business drivers or goals can you align with? Can you create revenue opportunities or cut costs by reengineering business processes? If so, sell SOA as the technology to enable BPMS tools.

Step three - Find a strong executive sponsor on the business side to support this initiative. Remember, this must drive business value in business terms. Reusable business services means nothing to the business. Reducing costs, increased sales, and improved customer satisfaction does.

Step four - Create a multi year vision supported by a road map of projects that deliver incremental value to the business in short time frames (2-4 months or less). Produce a business plan with supporting financials for each and every project within the road map. If you try to justify the entire road map as one number, you are putting the whole initiative at risk. We found that justifying each project as a stand alone deliverable allowed us to get most of the projects approved and funded. Don't make it an all or nothing proposition. You will likely lose.

Step five - Present plan to executives, including vision, road map (future state), and financials. Show the ROI, IRR, and your best estimation of when the break even point is. It helps to know your executives and what their thresholds are. If you know this information, keep working the plan until you can produce a road map that meets their needs for an acceptable investment. If you can't produce numbers good enough, either you picked the wrong initiatives or the time is not right for you to pursue SOA.

Step six - If you successfully secured funds, now the fun really starts. Now comes the SOA planning and change management (culture) challenges. Go to websites like Zapthink or take their 4-day bootcamp to figure out the best way to approach SOA. No need for me to publish that here when there are many great resources available on that topic. Here is a link I did on change management a while back.

That is a recipe that has worked for me. As I said before, the problem with SOA is not the technology. Only people can screw up SOA. That doesn't imply that SOA is easy, but all failures point to one or more of the following:

• No business buy in
• No executive support
• Poor project management
• Lack of understanding of SOA concepts
• No governance
• Doing SOA "on the cheap"
  

None of these are problems with technology.

I attended Zapthink's Practical SOA event on Tuesday in New Jersey. There were many great presentations from both vendors and practitioners. There were three different case studies presented including mine which was on selling SOA to the Business (the video will be posted soon). What was interesting to me was the three different paths the companies in these case studies took. The first case study was from The Hartford. They have a well established governance model and are very far along into the maturity model. If you read a text book on what SOA governance should look like, it will look like the Hartford. They have their processes so buttoned up that they even tie developers' annual review process to how they adhere to Hartford's best practices in reusability. A key take away is the fact that this took several years and a firm commitment from their leadership team to put this in place.

The second case study was from Lehman Brothers which was implemented in a totally different fashion. In this scenario, the governing body had very little control and power over the distributed development groups. So instead of just giving in and giving up, they took a different approach. They leveraged tools and some custom code to discover web services and usage of services in the repository. They would receive a page anytime a new service was discovered. Then they would study the service to see if it was constructed the proper way. If there were opportunities for improvement, the governance team would engage in conversations with the service owners to coach and mentor them on the proper design and deployment of their services.

In my scenario, we have a totally different story. Because we were so successful in selling the business on BPM and SOA, they funded the initiative and targeted very aggressive delivery dates for key functionality. That did not leave us enough time to plan and implement a governance model. So we are establishing a road map for delivering governance one step at a time. We understand the risks of not having enough governance up front and expect some headaches along the way, but the business was not going to wait a year for us to put those processes in place.

So theory and text books say that you must start with governance. The reality is you evolve governance over time. I highly recommend attending these Practical SOA conferences if you get a chance. I jokingly refer to it as group therapy because we are all sharing our lessons learned.
If you missed the conference, there are two more scheduled. The next one is in London on April 25 and the last one is in Las Vegas on May 16. I also highly recommend the LZA SOA Bootcamp which I recapped a while back. Ron at Zapthink told me that they are targeting May 5-8 in New Jersey for the next boot camp if they get enough people interested in it. Send Ron an email at info@zapthink.com if you want to attend.

I just realized that I wrote my first blog post over a year ago on March 18, 2007. Since one of my main reasons for blogging is to share my lessons learned, why not share what I learned my first year blogging? Last year I wrote a post called Why I started blogging and mentioned these benefits...

...I have benefited from it in many ways:

1. It has taught me how to write better.
   
2. It forces me to research topics thoroughly.
3. I have built a network with some top notch people in the industry.
4. It allows folks at my work to see what my thoughts are on different topics (I lead the architect group)
5. I get feedback (good & bad) on my thoughts and opinions.
   
6. I am able to see other point of views. People tend to challenge ideas more readily in blogs then they would face to face.
7. Most importantly, I learn from other people's experiences

Now after a year worth of writing, I believe that this was one of the best decisions I have ever made in my career. Not only have I increased my knowledge of enterprise architecture, SOA, open source, and other areas of interest, I now have a tremendous network of experts in various fields across the globe. Prior to blogging, most of my research came from books, conferences, and magazines. As I have mentioned in the past, books become outdated and conferences and magazines are usually influenced by vendors and/or people without hands on experience. There is nothing better then collaborating with real architects like Nick Malik, Todd Biske, and Eric Roch. If you want to know how stuff really works, read their blogs. I was so impressed with Eric Roch's knowledge of SOA that we hired him and his team to help us implement SOA.

I have also started building great working relationships with various thought leaders in the world of SOA. We had Jason Bloomberg from Zapthink come in for an excellent 4-day boot camp (see recap here) and I am presenting at Zapthink's Practical SOA event on the 25th. We also had testing expert Randy Rice come in for a 3-day training session on SOA testing. Having smart people like Eric, Jason, Randy, and Ron Schmelzer and Dave Linthicum of Zapthink in your network can only help.

Another great benefit I have received from blogging is being able to show case my thoughts and improve my product (me) in a very competitive world. I have had so many people reach out to me for interviews, job offers, advice, or to simply discuss certain topics. Scores of people have invited me to their LinkedIn network or have subscribed to my blog. All of these people in my network present countless opportunities to help in my career. These people may wind up assisting on one of my projects, collaborate on ideas that may help me solve a problem, or present me with an opportunity that could help me meet my career goals.

Another benefit of blogging is that I have gained a huge competitive advantage on my competition. People with similar career aspirations who don't write and/or read blogs will fall further and further behind those of us who are learning and collaborating daily with some of the smartest technologists in the world. Also, blogging has turned me on to numerous types of Web 2.0 technologies like wikis, social networks, Twitter, and all kinds of other innovative tools. I believe that the more in touch a person from my generation (born in '65) is the more prepared that person will be to lead the younger generation as they enter the work force.

And finally, blogging has kept me from becoming complacent. I have been at the same company for almost 13 years. It would be real easy to get complacent and only focus on the technologies that are currently in house. Before I started blogging I was not investing anywhere near the amount of time I spend now researching various technologies. The best part about it is that it is fun and is not a burden like reading book after book. The beauty of a good blog, whether you are writing it or reading it, is that it is short and to the point and you don't have to invest hours on it like you do with books.

So my big lesson learned after my first year is that blogging is a great way to get connected with the world, improve your product, and stay current in technology. And if you are good and attract some traffic, you can even get paid (Thanks ITToolbox)!

I just read an interesting essay by Paul Graham titled You Weren't Meant to have a Boss. It is a little long but an excellent read if you have the time. An analogy that he uses that caught my attention is his comparison of animals in the wild and animals in the zoo, compared to programmers in startups and programmers in corporations. A lion in the zoo is almost lifeless and painfully lives simply for the next meal and to get through the day. A lion in the wild is free to roam, must kill or be killed, and is always alert.

Then there are the programmers in the wild. Paul sees programmers in startups being very innovative, passionate, and driven. Programmers in the zoo are more conservative, less motivated, and sometimes extremely constrained. I have been at the same corporation for almost 13 years now and in corporate America for 23 years. I have seen many people come and go and here is a pattern that I observed across my entire career.

1. New employee enters company full of motivation and fresh ideas (In the wild)
   
2. Employee begins the socialization process (Captured)
3. Employee becomes complacent (In the zoo)
4. Employee leaves (In the wild)

Sometimes this process is quick but most of the time this is a multi year evolution. What always catches my eye is that they always have the same look in their eye the day the walk in and the day they leave. That look is the look of a lion roaming the prairie. In between those two times, they often look like the lion at the zoo.

So how do corporations create an environment for programmers in the wild and prevent their staff from feeling like caged animals? If I had the answers I would be making a ton of money telling everyone how. My vote would be to use a collaborative leadership style as opposed to the normal top-down approach. Use collaborative tools like wikis, blogs, and social networks to foster information sharing. Act like a startup instead of a 100 year old corporation. Create an innovative environment and create a reward structure that rewards the people who build applications that work, not the people who fix their own crap that breaks.

How do you stay in the wild?

There has been a lot of talk about SOA failures lately. There are many pessimists who haven't even dabbled in SOA who have simply wrote SOA off as the next buzzword that carries no merit and will soon be displaced by the next big technology fad. These are obviously people who either did not do their homework or simply have deep scars from past experiences working on new technologies that promised to save the world. This time it is different. SOA is all about fixing business issues, not technology issues, if you chose the right goals.

As Todd Biske wrote, many companies are heading down the SOA path to "increase agility" and "reduce costs". Those are great goals and totally achievable but if you don't tie your SOA goals to business goals, nobody outside of IT will care. This presents a few problems:

1. With all of the projects that are on IT's plate these days, it can be extremely challenging to get funds and focus for another IT project.
2. Although these are good goals, it may take years to achieve these goals. There is a huge upfront cost in software, architecture, and ongoing labor. Management may not have the patience for another multi year effort without any near term pay back.
   
3. Business priorities usually take precedence. When a new critical business opportunity comes up, it may take priority over SOA. Staying focused could be a challenge.

These are some of the reasons for the "failures". Most failures can be attributed to people, not the technology. But it is not all doom and gloom like the recent discussions on the web is leading us to believe. If you make the proper business case, SOA can transform your company and lay the foundation for future wins in the area of agility, flexibility, quality, extendability, and even profitability. Here's how.

Although SOA done right can achieve great things for IT, it is the combination of SOA and BPM that does great things for the business. If you can get the business excited about BPM, you can leverage SOA as the technology that makes BPM work. At my company, we convinced the business to go through a business process assessment. We mapped out both the current and future state business processes and identified a multi million dollar opportunity with the following business objectives (not IT objectives).

• Strategic
  
• Improve customer satisfaction
• Reduce time to market for new products
• Operational
• Enhance productivity and efficiency
• Improve quality
• Financial
• Control and manage costs
• Enable revenue generation

These are all objectives that the business can understand and are easy to measure. Measuring IT objectives such as agility and flexibility are extremely challenging and not tangible to business people. With key business drivers like the ones I mentioned above, the business gets on board and starts championing key BPM/SOA initiatives. In our case we built a three year road map of projects that aligned with one or more of these objectives. Each project had its own business plan and was blessed by the CFO. This translated into three years worth of capital that was set aside for our BPM/SOA initiative. That's focus and that's commitment from the top.

I believe that the reason for many of these "failures" is that the original goals of these SOA initiatives are not focused on business drivers. We rarely even discuss the IT benefits with the business. Our ROI on the business side is so compelling that there is no need. We try to keep all discussions focused on the business so they see these projects as business projects and not IT projects. The key take away from this is that the business can see benefits of BPM/SOA as soon as you deliver the first project. It can take IT 2-3 years to achieve the technology benefits. The reason for this is that you will spend the first couple of years creating services. Eventually you will reach a point were you are consuming more services then you are building. Once this happens, then IT starts achieving its goals.

This seems to be a much debated topic so I would appreciate some feedback.

Recently the SOA discussions have turned ugly and everyone is talking about SOA failures. As Eric Roch said yesterday:

It is troublesome to hear SOA architects argue about the arcane details of SOA implementations, especially when there is no grounding in actual requirements.

Eric goes on to say that...

SOA should have a business sponsor and a steering committee like the huge IT initiative that it is. SOA should change the business and for the better! In the age when the vast majority of IT are buying not building applications many SOA pundits talk as if we can throw everything away and start over for the sake of architecture purity. The fact is we are stuck with legacy systems and are constrained by the SOA strategy of the application vendors like SAP and Oracle.

Eric seems to be the only person out there who agrees with me that SOA should be sold to the business. I have constantly been told my numerous industry experts and popular bloggers that this is impossible and is a total waste of time. Maybe I need to clarify my position and finally convince some people that this is the way to get the business to support and fund your SOA initiative.

Selling SOA to the Business
When selling SOA to the business, you must talk in business terms. In fact, you shouldn't even mention the word SOA. My company went through an impressive growth spurt over our first two decades growing at rates of 20-30% annually. Over the past few years our growth has peaked and now we are growing at a more modest rate. Now that things have calmed down from the high growth years, we are looking at ways to control costs. One area that has tons of opportunities is our business processes. We had been moving so fast for so many years that our processes have become largely outdated and inefficient.

A few of us in IT saw a huge opportunity for the business to reengineer their business processes. We convinced the business to hire a consulting firm to perform a business process analysis. The consultants documented the current state processes, worked with us to derive the future state processes, and performed a gap analysis that uncovered a huge opportunity with a very large ROI. Now the business was motivated because they could envision a future state where they would improve the time to market for our products, improve customer satisfaction, reduce the learning curve of their systems, and streamline operations. They were hungry for change.

That opened the window of opportunity to sell SOA. And sell it we did! We did not talk about SOA in technical terms. What we did tell them is that by leveraging a "new" technology, we could automate their entire workflow from contract to delivery without having to rewrite any of our backend systems. This new technology would allow us to connect their new web based systems to the existing systems through an "adapter". Of course, by adapter I mean services, but that term means nothing to the business. So here is what the business heard:

• BPM will make our life easier, eliminate waste, and save us a ton of money
• If we buy IT this "new" thingy, we won't have to wait years for them to replace our current systems.
• IT will be able to deliver these new web based systems this year!
  

The result, the business funded both the BPM and SOA technologies and three years worth of projects as defined in our 3 year SOA road map. We created a steering committee led by the business that is the driving force of our BPM/SOA projects. We delivered our first project within a few months of buying the software, and have the next eight projects in the hopper to be delivered over the next two months. We are now starting another round of projects for a different business unit and discovering that we are already achieving a 30% reuse rate. All of this in less then 10 months.

So who says I can't sell SOA to the business? And who wants to argue that BPM is not the killer app for SOA? I am sure that I will get the same responses from the same people, but my project is living proof that IT can get the business to drive SOA. Without the business on our side, SOA would be nothing more then a fantasy for us.

If you read the numerous technology blogs daily like I do, you soon realize that most people still don't understand SOA. Today I read this article from Joe McKendrick called Why even the best SOAs are stalling. In this article Joe discusses an article by Anne Thomas Manes where she discusses how she has only come across one company that has realized any value from SOA. In her article she referred to an article from Ron Schmezler at Zapthink called Why Service Consumers and service providers should never directly communicate. Apparently this article caused all kinds of heated debate on the message boards. Her conclusion is whether you agree or not with Ron that SOA and integration are two different things, the discussion is irrelevant.

....this technology discussion is irrelevant.....It has become clear to me that SOA is not working in most organizations.

So why are so many organization struggling with SOA? And why are even the organizations who are building SOA the "right" way not realizing the value? In my opinion, I don't think people truly understand SOA and its value proposition.

Business Value
The business gets value when SOA is used as an enabler of BPM. You can reengineer your process all day, but you need to allow these business processes to communicate with your legacy systems. The business can't wait for IT to blow up legacy applications in order to create new user interfaces with robust workflows under the covers. Instead IT must abstract the legacy layer and make it easy to build composite front end applications that leverage years of investments in the legacy applications. This allows IT to deliver huge amounts of value to the business in a relatively short amount of time (if done right).

IT Value
The value for IT is in reuse and speed to market. As your SOA matures, the amount of reuse grows exponentially. As Jason Bloomberg explained in Zapthink's architect boot camp, if you architect SOA correctly, you will move from creating services to consuming services. Once you have built a good baseline of abstract services, you can quickly meet the business's demands by assembling business services rather then building them from scratch each time. Think of it as Lego building. If you start with a hand full of white and red Legos that are rectangular in shape, you can create a few nice structures out of them.


Then you add more colors, followed by new shapes (circles, squares, arcs, etc.), followed by custom pieces (parts for trucks, trains, buildings, boats, etc.) and soon you can build an unlimited amount of structures.



The Real Problem
What I see as the real problem preventing companies from successfully deploying and realizing value from SOA is they don't fully understand SOA and they underestimate the amount of change to the culture. So here are the list of non technical issues that will kill your SOA project:

• If you don't align SOA with a key business driver, you greatly reduce the odds that you will ever reap the rewards of SOA.
  
• If you don't include BPM in your SOA implementation, then SOA becomes just another IT buzzword for the business and not an enabler.
  
• If you don't take a proactive approach to change management, resistance will prevail and you will spin your wheels dealing with change (been there, done that).

Key take away
The problem with SOA isn't SOA, it's people. People must understand SOA and the importance of aligning their initiative with a key business driver. BPM is the killer application that can get your business sponsors on board. And finally, you need strong leadership with a focus on change management to pull it off.

Whether you are implementing an Enterprise Architecture, SOA, or in my case, both, dealing with change is by far the hardest part of the project. I just happen to be taking a graduate level leadership class right now (timing is everything!) and we are studying different change theories. The one that I like the most is Kotter's 8 steps for transformation.

1. Establish a Sense of Urgency
2. Form a Powerful Guiding Coalition
3. Create a Vision
4. Communicate the Vision
5. Empower Others to Act on the Vision
6. Plan for and Create Short-Term Wins
7. Consolidate Improvements and Produce Still More Change
8. Institutionalize New Approaches

If you take these steps and apply it to EA or SOA, you can get a list of steps like this:

1. Build strong business case
   
2. Secure executive sponsor and top level buy in
   
3. Create a Road Map
   
4. Communicate the Road Map
   
5. Empower Others to Act on the Road Map
   
6. Start small, deliver early and often (agile)
   
7. Expand, leverage reuse
   
8. Govern

Most articles that I have read discuss two critical elements: the technology and governance. Not enough people are talking about change management. I would like to invite my fellow EA bloggers and industry experts to write a blog post (or two) on how to effectively promote change throughout the organization.

I have been blogging about my Web 2.0 experiments at work and recommended that we should just do Web 2.0 instead of trying to justify it. With so many open source solutions available for wikis and blogs, the best way to get traction with Web 2.0 technologies is to casually bring it in house, plant the seeds, and let it grow like weeds. You can have a large amount of people using these tools quicker then you can try to sell the value to an older generation of decision makers who are not familiar enough with the tools to understand the value.

In my post Leveraging Enterprise 2.0 I mentioned how we would launch our blogs. Each member of the architecture team is maintaining their own blog about their area of expertise. I am blogging about the vision of our enterprise architecture and SOA initiatives. The key to getting people to view these blogs is two biweekly emails. The first is a biweekly update from our CIO. The email is simply a short sentence and a link to his blog. On his blogroll is all of the architect team's blogs. The email goes out to all of IT which is roughly 200 people. His statistics show roughly 150 unique visitors. That's 75% of the staff that is reading the his blog!

On the weeks where the CIO does not update his blog, the architecture team sends their biweekly newsletter out. This email has a paragraph or two of current news and then has links to the latest blog articles with a brief summary for each team member's blog. My blog has reached roughly 40% of the staff where as other members of the team are falling in the range of 10%-33%. Not bad for our first 6 weeks.

Since launching these blogs, I have received requests from marketing, sales, and public relations to meet about possibly extending blogs to their departments. In an IT strategy session today, one of the teams working on our "people strategy" recommended more blogs to improve communications. Like I said before, build it and they will come.

My goal by the end of the year is to make internal blogs a normal part of our daily lives and have as many senior level managers as possible blogging at least once a month. The architect team has found that blogging has created several quality discussions with people who they don't get a chance to interact with that often. As time goes on, I expect to see more comments submitted and even requests for blog topics coming our way.

We are also leveraging an enterprise wiki where we are storing all of our enterprise architecture and IT Center of Excellence (CoE) content. Our company is in the infancy stage of SOA and BPM and we are loading up our wiki with tons of information like the developers' guide book, SOA best practices, standards and policies, etc. We are also using it as a collaborative tool as the CoE starts establishing our new SOA standards and design review processes. We are trying to develop these processes without using any emails. We are only allowed to use face to face discussions and the wiki to come to consensus.

In just six short weeks these Web 2.0 tools have started to make an impact in our ability to improve communications. There are still some people who laugh at the notion of blogs and wikis, but in time this will become as normal as email and the telephone. And the beauty of it is that we didn't pay a penny for any of it and we didn't have to sell it to anybody. We simply built it and they are coming.

A great blog for more information on wikis is Stewart Mader's Grow your Wiki.

Bringing an Enterprise Architecture to your company can be a battle, especially if the current culture is used to application silos and has no clear picture of the true costs and performance of IT. The most challenging part of implementing EA is dealing with culture change. I stumbled across a great article today in the current issue of the Architecture and Governance magazine. Here is an important quote from this article:

“Twenty percent of our success is the new technology that we embrace . . . but 80 percent of our success is in the culture of our company.”

The article goes on to describe characteristics of a culture where EA is accepted:

• Collaborative teams vs. stovepipe
• Information sharing vs. hoarding
• People-oriented vs. bottom line focus
• Emphasis on standardization vs. technological differentiation
• Adherence to governance vs. “acting first and asking permission later”
• Business focus vs. technology for technology sake
• Performance measure (accountability) vs. "seat of the pants"

Here is my take. If you have a culture that fits the above description, you probably already have a well established EA. For the rest of us, we need to identify which characteristic(s) we are missing and devise a plan to change the mindset. Obviously, the more characteristics of your culture that are undesirable for an EA, the harder your job will be. David Linthicum wrote this piece yesterday called Why Enterprise Architects Continue to Fall Short with SOA…and Enterprise Architecture. In this article he points out three reasons why architects fail trying to deliver SOA. The last one is fear of change.

Fear change. If things are bad, than change is typically good. Unfortunately, change also means risk, and risk is something people typically don't like. The fact of the matter is that people are rewarded for maintaining more so than improving, and thus how many of the enterprise architectures out there are now layers upon layers of tactical one-off solutions designed to "keep things going a few more years." Somebody needs to have the political will to figure out a long term solution, using sound enterprise architecture approaches, including SOA.

Dave's point "Somebody needs to have the political will to figure out a long term solution" is what I am referring to as "fighting the good fight". As enterprise architects, chief architects, CIOs, and CTOs, we owe it to our respective companies to deliver value, efficiencies, and enable our business partners to achieve their goals. Too often, IT shops have become bogged down in keeping the lights on because they always take the quick and dirty route to solving problems. Always remember, the dirty hangs around long after the quick is gone. It is time to fight the good fight and build an architecture that allows your IT shop to be responsive to the business (agile) while building a sustainable architecture that supports both short and long term needs.

Last week I wrote a post called "Do you have an Architect personality?". James McGovern asked that I follow it up with a post about an architect's abilities. One of the most overlooked abilities of an architect is the ability to lead through change. Too often, the architect role is looked upon as strictly a technology role. This may be true if an architect works on a well established EA. But for most of us, either we are trying to implement EA or we are in the early stages of EA maturity and are still battling with politics, nay sayers, and resistance. Architects must be leaders and help explain WIIFM (what's in it for me) to each person who still has not joined hands with EA. Why must we change? What value does this bring? How will my job change? How will we have time to do it this way? These are all familiar questions that architects are faced with.

So what are some of the abilities that architects need?

• Emotional Intelligence - ability to perceive, assess, and manage the emotions of yourself or others.
• Leadership - ability to affect human behavior to accomplish a mission or goal
• Effectively Communicate - ability to clearly articulate (verbal and written) one's message. Includes ability to persuade, negotiate, articulate, sell, and others.
• Intelligence - ability to learn and retain information about new technologies, processes, and solutions.
• Problem Solving - Find solutions to complex problems, both technical and non-technical
  
• Vision/Strategic - Ability to predict future patterns and plan accordingly. Create roadmaps and action plans for accomplishing goals.

This is a short list. I could go on forever but these are the key ones. To fight the good fight, one must have the determination and stamina to move beyond the daily grind and strive for the end goal which is to establish a functional and mature EA. If one chooses the easy way out ("that will never happen here" or "they are not ready for this yet"), then they are not doing the role of an architect any justice. Instead, they are simply a senior developer with a fancy title.

I have been experimenting with various flavors of Linux over the last several months. The last time I wrote about it I mentioned that on my newer 64 bit laptops, only Mepis could connect to my wireless network out of the box. On the desktops and older hardware, all of the distros that I installed successfully had no compatibility issues with any hardware components. They also could see my network.

This weekend I finally found some time to look into the wireless issues on both the Ubuntu and Kubuntu distributions. After much experimentation and little success, I finally found a thread that solved my problems. In an effort to help others, I felt that I should post my fix here.

This thread is specifically targeted for Dell laptop users running (K)Ubuntu. There are a lot of steps but if you follow them all you will have your laptop connected to your wireless network in no time. Before you start, make sure the wireless switch on the front left hand side of your laptop is in the on position. One note, I did have to make a few minor adjustments to the script that was posted. First of all, I had several commands fail due to permissions. I had to do a few chmod commands to allow write access to various directories and files. Second, there were two wget commands that are issued to retrieve a file from Dell and the ndiswrapper file. I had to precede the commands with the command "sudo" to get the appropriate privileges.

wget http://ftp.us.dell.com/network/R151517.EXE
wget http://superb-east.dl.sourceforge.net/sourceforge/ndiswrapper/ndiswrapper-1.51.tar.gz

should change to

sudo wget http://ftp.us.dell.com/network/R151517.EXE
sudo wget http://superb-east.dl.sourceforge.net/sourceforge/ndiswrapper/ndiswrapper-1.51.tar.gz

Once I finished running all of the necessary commands and rebooted, my wireless light indicator finally shined blue. Then I had to install the Wifi-radar using adept_installer. Once I did that my laptop was able to connect to my network and I became a happy man.

I also had an issue with my sound card. A quick search on the Ubuntu Forum and I found this simple one liner.

sudo apt-get install linux-backports-modules-generic and then reboot.

I cut and pasted the commands, ran it, rebooted, and presto....Sound! If it still does not work for you, make sure your volume controls are not set to low or mute.

So hopefully some people will find this post and quickly resolve their issues on the newer Dell laptops. Once these issues are put to bed, you can sit back and enjoy the experience of a fast, secure, and a free operating system for those like me who dumped Vista.

I am currently enrolled in an executive MBA program and my current class is about Leadership. As part of our group project we are working on we took the Jung Typology Test (personality test) to get our Meyer's Briggs indicators. After answering the questions on the test you get graded in four areas:

1. Extroversion vs Introversion
2. Sensing vs. iNtuition
3. Thinking vs. Feeling
4. Judging vs. Perceiving

I am a ENTJ which means I scored higher for the following (Extroversion, iNtuition, Thinking, Judging). These four letter codes then map to certain personality types which fall into four distinct temperaments:

1. The Guardians - 40-45% - administrators and conservators
   
2. The Idealists - 8-10% - mentors and advocates
   
3. The Artisans - 35-40% - entertainers and operators
   
4. The Rationals - 5-7% - Engineers and coordinators
   

Within each temperament there are four types. The four types of Rationals are:

1. Architects - Their major interest is in figuring out structure, build, configuration -- the spatiality of things.
2. Field Marshals - organize their units into smooth-functioning systems, planning in advance, keeping both short-term and long-range objectives well in mind.
3. Inventors - have an eye out for a better way, always on the lookout for new projects, new activities, new procedures.
4. Masterminds - natural brainstormers, always open to new concepts and, in fact, aggressively seeking them.

As I read through the information, I found it interesting that only 5%-7% of the world falls into the Rational personality type. And within the Rationals, only the Field Marshals prefer to manage. These are the Chief Architects which represent only 2% of the population. Masterminds tend to stay in the background and only insert themselves into leadership roles when they see others fail. Masterminds represent only 1% of the population. If you combine the Field Marshals and Masterminds you only have 3% of the population that represent the characteristics of a Chief Architect. Enterprise architects fall into the inventors and architects types which make up only about 3-5% of the population.

To make a long story short, it takes a special breed of people to fill the role of an architect. And many of these special people have no desire to take on the leadership tasks that make up a Chief Architect. Why do I bring this up? Well, so many companies are looking at investing in SOA. SOA requires an enterprise architecture which requires architects. There is already a shortage of "real" architects and SOA is going to make those resources in more demand. That's good news for architects (demand) but bad news for companies (supply). Companies that can't distinguish between architects and architect wannabees are going to be in for a rude awakening. If you want to know if your candidate is a real architect or not, read this article from Zapthink and test your candidate on his/her understanding of what SOA really is.

Take the test and see what your personality is. I am a Field Marshal.

I summarized day 1 and day 2 of Zapthink's LZA SOA Bootcamp. This post will summarize days 3 and 4 and provide my overall assessment of the class. The last two days covered topics like testing, governance, SOA Pilots, BPM, funding, and pitfalls. Here are some key take aways:

One step at a time. Just like establishing an EA program from the first time, you need to start small, iterate, make adjustments, and move on to the next challenge. Implementing SOA is a long journey. Don't try to do it all at once!

Abstraction is the key. Your services should be vendor independent (ex: should run on any ESB without changes to the service), business process independent, database independent, etc. If this is not the case, then you are not doing SOA. Most likely, you are doing ABOS (a bunch of services).

The "Tipping Point" - If you do SOA right, you will reach a point where you shift from creating services to consuming services. When you find that you are spending most of your time assembling SOBAs (service oriented business applications) then you know you have achieved SOA. Let the Lego building begin!


Start with a pilot. Don't forget that governance and architecture should be piloted as well. Don't just pilot services. It takes services, governance, and architecture to create SOA so don't leave any of these out of your pilot.

Design time governance - Ensure that team members are following best practices that apply to services. Governance should not be a burden and a ton of paper work. It should be value add and help the team build a true service oriented architecture. Design time issues include versioning, metadata management, policy management.

Run time governance - Enforce and monitor run time policies and SLAs. Service development doesn't stop when a service is deployed. The service lifecycle continues through run time. We must plan for ongoing change of services. Run time issues include service availability, policy enforcement, SLAs, controlling total cost of ownership (TCO).

Don't test the architecture - Test the individual components and how they integrate together. Divide architecture into domains and verify the domains. Things you need to test: services, security, business processes, integration, and also the governance. Services should run without dependencies. Test services across multiple platforms and test for abstraction.

Funding and the business case - Don't talk about the technology, talk about the business problem! Here is how I sold SOA at my company. Key drivers are reuse, greater visibility into business processes, business empowerment, business agility, lower integration costs. Create a roadmap and estimate the each deliverable along the way. Don't forget to fund the organizational changes, training, and support.

SOA Pitfalls - Don't let the vendors or consultants drive your architecture. Create versioning policies. Without these you may not achieve loose coupling because you might break the contract your services have with their consumers.

Organizational challenges - Here is the biggest challenge of them all. You can always find a bunch of smart people who can figure out the true meaning of being service oriented. But how can you make people change? Remember the days of trying to get mainframe developers to adopt client server? Get ready to live those days again. Since SOA blurs the lines between applications, middle managers may look at SOA as a threat. Typically, the architects do not have the enforcement power/authority needed to enforce best practices. This is a major challenge with SOA.

Still maturing - SOA best practices are very dynamic. This technology is still maturing and the vendor tools and standards are still evolving.

What's next? - Web 2.0, Enterprise Mashups, and complex event processing all are natural extensions of SOA.

Final Summary -
This was an outstanding class. I highly recommend this class for any organization that plans on tackling SOA. Jason Bloomberg was a fantastic teacher who kept us all awake and interested for four days. The Jeopardy exercise at the end was a nice way to finish off the bootcamp. We had many hands on group exercises and student testimonials that helped balance the content between slides, discussions, scenario planning, and lesson learned. This class was some of the best money I have spent to date on my SOA initiative.