When you’re coming to implement SOA for the first time you probably focused on the application and technology aspects, but as you drill deeper and deeper into it you’ll found out that going through SOA is actually changing every aspect that your IT department is working. I personally think that we shouldn’t call it SOA any more, That’s IT 2.0!

If you split IT into four main domains you’ll find out that each domain will be changed once you start to implement SOA. In the business domain you’ll experience changes in the way that you model the business as well as need for more deeply involvement of business side of the enterprise in the work that you are doing. SOA will also introduce new  roles with new skills that you’ll need to adopt as well as new training models for your customers. And last but not least SOA introduce new concepts such as SaaS and Cloud Computing that might infect the business and the way your IT is working.

I didn’t start from the business by chance. The reason that I did it is because I believe that the business is the cause for SOA, although not from the reason that you’re thinking right now. As far as I can see it the business will be perform with or without systems. It has been done in the past (and I know several good examples even today J ). With or without IT businesses are using information to do their work. IT helps organization to manage and process information more efficiently.

Business are complicated and dynamic and they become more and more complicate and dynamic. So if IT manage information and information derived from the business any change in the business reflects IT. I believe that we can see this influence over the time. We had few major changes in IT, from Main Frames to Clients Server model, WEB application and now … Yep, SOA. What I found out is that those IT waves are consist efforts of the IT to manage to solve the business problems, but without any real success.

One of the lessons that we need to learn from that is the need to better know our enterprise information. We need to model this information into conceptual and logical models, we need to agree with business guys who is responsible for information, we need to set which information should be available 24*7, we need to agree who can see and manipulate Information. But the most important one is the need to understand that Information is the basic building blocks for our IT work.

It goes without saying that there are many changes in the way that we’re designing, developing and maintaining applications. New design methodologies should be in place both for analysis and designing of systems, as well as developing methodologies of systems. The technology domain introduce new technologies needed to support SOA, such as ESB or SOA metadata technologies. SOA also introduce new demands that out IT infrastructure should take in account, like our cooperate bandwidth.

There are also changes in what I call 3rd dimension aspect such as the way we’re doing governance, being complaint to law and regulation, enforcing security and many other policies.

I didn’t went through all of the changes but it clear enough that we can call it IT 2.0. if this change is so fundamental it probably very hard to be done. Well, that’s true and this is the right place to mention Enterprise Architecture as a tool that might help you. Want to learn more about it? Come to hear me on the upcoming “The Open Group” convention in Glasgow.

One of the most common tasks of IT departments is to move information between different roles in the enterprise and to enable them to view and manipulate the information as well as get insights out of them. Each one of those roles wants the data to be moved using a different vehicle, but dose this mean that you need to create a different solution for each role. Each one of those roles wants to change the vehicle when his environment changed to be able to better work in his new environment. Are you building him a new SUV instead of the previous Hammer that he used?

I’m not using the car metaphor just for fun, the car industry managed to come up with architecture that enables them to create different types of car but based on the same chassis. Are we as enterprise architect doing the same?

When you hear the term application infrastructure you probably think of software infrastructure like databases, GIS software, visualization tools and other technology and hardware infrastructure that usually support our applications those days. But, are just technologies and commercial software can create your application infrastructure?

If your enterprise decide to be based on SOA as leading architecture style and your implementation is based on your enterprise business capabilities, you probably can take your IT infrastructure into new heights.   Creating collection of services that reflect the business capabilities actually create new IT infrastructure, a business Infrastructure that enables IT to create different bodies based on one IT chassis. This application platform together with the traditional infrastructure (that I just mentioned) is the IT chassis that you can based your IT vehicles on.   

Building such IT chassis enable you to create different bodies on top of the chassis and eventually reach much more reuse and flexibility. Those bodies are workflows that we build in order to serve our clients needs.

Using SOA to create services infrastructure is not so obvious. To build such infrastructure there are two main points that you better think of:

-         A model that describe what types of services (granularity level) needed, how they related to business capabilities, how they compose business processes, what their relation to the enterprise information model and what the software components that exposed them needed to be define.

-         The traditional way of building software needed to be changed. Production of services needed to be separate from production of workflows that uses services. If the development of the chassis is being done by the same team that develop the body you’ll fond that application aspects were implemented inside the chassis. The result is a chassis that is less generic and will support fewer bodies.

I wrote an article based on my experience in SOA and fortune 500 firms in the last year:  

Enterprise architecture framework is used to carry on enterprise architecture work for enterprises. Enterprise architecture helps enterprises to deal with today challenges such as low and regulation compliance, agility of the business and the IT, managing portfolio, making the CEO vision into reality and others. Dealing with business and IT agility touches SOA and services. In this article we’ll see how we can use architecture framework to map enterprise level services and set their granularity.

you can read the article on my site: http://www.theeagroup.net/ea/Default.aspx?tabid=39&mid=357&ctl=Details&ItemID=7

and I'll be happy to hear comments here.

Natty.

I just started new working group around Enterprise Architecture: http://aggreg8.net/blogs/enterprise_architecture/default.aspx. Enterprise architecture, not software/system architecture. My first post is about enterprise architecture definition mainly to focus the working group around enterprise architecture. 

So if you have any Issue, Problem or something to share in the enterprise architecture field I'll be happy to see you there. 

Coming from pure IT background I can understand the discussions about the right way to implement SOA at enterprises, but the reality shows that the right way to adopt SOA is to convince the business side regarding the necessity and contribution of SOA to the business. Let’s face it, IT is just a tool or enabler for the business to reach it goals and objectives. In a matter of fact since IT serves as a tool to manipulate the enterprise information, it’s always reflects the situation of the enterprise information. The enterprise information is affected by the way the business is running, therefore there’s a direct influence of the business on the IT.

Therefore you can find a great or a bad IT architecture and use it for the IT side, but if you manage to solve IT problems without solving business problems you’ll probably fail. We are all familiar with the IT spaghetti that all the IT knights tried to solve. But have you ever thought why we end up with this IT spaghetti? Maybe this spaghetti is a mirror of the business spaghetti! If this is the case it doesn’t matter which IT architecture we’ll follow. The right solution here is to re-architect the business side first. 

People like the analogy between city planning and enterprise architecture, so I’ll use this analogy to prove my point here. The business architecture of enterprises is similar to the city planning decisions made by the city mayor and the city committee. If they have wrong decision regarding the distance of the city international airport from the city, it doesn’t matter which architecture the city planner will use for transportation and human (Information), buildings (application) or roads and railways (infrastructure) the city still have a problem. Just after re-architecting the “Business” the problem can be solved.

The problem that we face today is that SOA is a technical architecture pushed by the IT but not polled by the business side of the enterprise. The ironic part is that the ideas behind SOA might help enterprises business to re-architect the business side and to solve the business spaghetti. This business spaghetti that will prevent us, the IT guys, to reach successful SOA based IT solutions. 

If you’re running SOA project or thinking about one you should have an enterprise architecture team that will support you through this process. Remember, without the ability to make business changes your SOA project will be probably doomed to fail.

It didn’t take 9 month, just six, but after 6 long and tedious months of work for SAP we present a sneak preview of SAP new enterprise architecture framework at SAP Teched. This framework has three main statistics:

a. Using the framework you can support both long term strategic work as well as short term tactical pain point solving.

b. It's a SOA oriented framework. You can use the framework to find out and show how services can help your business goals and objectives, and to find out what are the needed services for your enterprise and their level of granularity. 

c. we’re introducing EA styles, which are most of the building blocks (in each one of the enterprise domains) needed to create “an holistic view of the enterprise” for each industry. We manage to introduce styles based on SAP knowledge and experience in most of the industries.

I'll post more data in the near future because as far as I can see it any one can benefit from using this framework.

Nowadays I'm working on an enterprise architecture framework for one of the leading software vendors in the world (one of the big four). while creating the training material for the new framework this sentence popup in to my mind. BIST stand for Business, Information, Systems and Technology and the Idea (of course) is to use enterprise architecture to tame the BIST.

So are you taming your BIST? 

While attending a social event of enterprise architects I was asked (after being introduced) by a respectful CEO "so Natty, what exactly are you doing for living?" usually I'm explaining about EA, EA domains and how I help to align IT to business, but this time I replied "I'm an Information Technician!". You could see the puzzle in the man eyes, "You what?"
I'm an information technician. My job is to shape the way data organized, handled and maintained in the enterprise. My set of tools are business process modeling tools, data modeling tools, applications, systems, infrastructures and my experience. I use my tools to shape IT is such a way that it will fit, as much as it can, to business needs. The same as a dental technician will build dental crown/s that perfectly fit your mouth structure I'll build perfect IT solution that will fit your enterprise.
He smiled and went away, leaving me his business card. "Give me a call!" he said "I've got some rotten tooth in my mouth; I think you'll have a lot of work to do". After a week or so I called that man. "Ha, you're the information technician" he said. The call went on, but I'll write about it in another time.