Natty Gur

It's not SOA it's IT 2.0

nattYGUR — Mon, 07 Apr 2008 09:53:00 GMT

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.

Are your IT vehicles based on one chassis?

nattYGUR — Fri, 08 Jun 2007 07:14:00 GMT

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.

Using enterprise architecture framework to map services and set their granularity

nattYGUR — Sat, 28 Apr 2007 07:57:00 GMT

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.

New enterprise architecture working group on AGGREG 8.

nattYGUR — Mon, 13 Nov 2006 05:42:00 GMT

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.

SOA, It’s not about the IT It’s about the Business.

nattYGUR — Sat, 28 Oct 2006 09:21:00 GMT

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.

Now I'm a father .... of a new enterprise architecture framework

nattYGUR — Fri, 29 Sep 2006 01:17:00 GMT

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.

How to tame the BIST...

nattYGUR — Sun, 27 Aug 2006 18:37:00 GMT

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?

Business capabilities or business processes

nattYGUR — Fri, 28 Jul 2006 14:01:00 GMT

Business processes are used commonly for a long time. Most of the architecture community is using different notations for describing business processes. It doesn’t matter if it’s a known standard such as BPMN or custom notation, we are all finding ourselves describing business processes which are taking place in our enterprise.

Business capabilities, abilities or function are less common, although they might be more important to us as enterprise architects. If you want to understand why business capabilities might be more important to you, keep on reading this short post.

There is a basic difference between business capabilities and business processes. The first is “What” the business can do in order to reach it business goals and objectives, while the second is “How” the business is doing those abilities, or what are the actions that taking place in order to do each one of those capabilities. For example, we as human have capability of reading. In order to do this capability we need to see, understand characters, combine them into words and combine words into sentences. Needless to say that it’s much easier to grasp and describe business processes (or how we’re doing task) rather then thinking what are the capabilities that we need in order to reach our business goals and objectives. It’s easier to ask people what they are doing and simply to document it by following any description language.

Capabilities, on the contrary, are more difficult to deal with. They are more abstract, and everything with higher level of abstraction takes more time and effort. But, capabilities have one huge advantage. What the business is doing is rarely changed while how the business is doing it tend to change a lot. If we’ll get back to humans, the ability to read always exists. Reading might be achieved differently by blind people, but they still have the ability to read.

For enterprise architects who are building agile architecture it seems that abilities (which rarely changed) are more important then business processes (which tend to be changed). The ability of enterprise architect to command his enterprise capabilities is vital to create agile architecture that will support business changes over time. To better command your enterprise business capabilities set what are the basic attributes that each one of your enterprise capabilities should have and assign them values. After understanding capabilities start to map and model the processes that the enterprise is doing to achieve those capabilities. If you’ll define the right capabilities and their attributes you can turn them into services that your enterprise need in order to reach it goals and objectives.

The Data-Centric Enterprise: A Blueprint for Enterprise Architectures

nattYGUR — Fri, 21 Apr 2006 16:24:00 GMT

In the upcoming EA summit 2006 (Key Biscayne) http://www.ftponline.com/conferences/eas/2006/strategy.aspx#datacentric I will speak about EA patterns.

Patterns have been in use for quite some time to work with system architecture and software design. Currently, enterprise architecture is one of the more complex undertakings in many organizations, and there are many enterprise architecture frameworks that organizations can adapt and use for the task. While those frameworks can be helpful for specific approaches and methods, they are not helping with the content of the outcomes, which very often is a task they have to work with alone. Enterprise architecture patterns should help with the outcome's content. Patterns suggest a set of blueprints for each one of the different architectures, and therefore decrease the resources and time needed to get successful and agile enterprise architectures. a simple and clear way of finding a match between enterprise and pattern is by using style. Styles employ a simple life metaphor to describe much more complex activities. This presentation will provide a discussion of design patterns, architecture patterns, enterprise architecture patterns, and styles. In particular, the discussion will provide insight into a new style that describes data-centric enterprises and provides the blueprints and proven concepts for business, information, system, and infrastructure architectures.

EA patterns are important part of NAAF continuum.

We hope to see you there.

The Information Technician

nattYGUR — Thu, 02 Mar 2006 05:13:00 GMT

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.

Introducing NAAF.

nattYGUR — Fri, 24 Feb 2006 19:11:00 GMT

For quite a long time I'm using an evolving version of TOGAF that I'm calling NAAF. This is an agile, SOA oriented, real life framework which based on my experience. The following presentation introduce basic concepts of that framework.

http://www.theeagroup.net/ea/Default.aspx?tabid=1&newsType=ArticleView&articleId=98

Enterprise architecture is the dentistry of the IT world.

nattYGUR — Mon, 23 Jan 2006 19:41:00 GMT

Enterprise architecture is the dentistry of the IT world! Yes, like people who tend not to pay a visit to the dentist until they can't stand the pain. IT organization tend not to take seriously (or even to ignore) enterprise architecture until it really hearts. You can go to the dentist and prevent your pains and you can start taking seriously EA and prevent pains, but for some reasons people not tend to do so.

Full post on IASA site.

How EA should work in parallel with other architecture efforts.

nattYGUR — Sun, 22 Jan 2006 16:43:00 GMT

As I already posted I'm engaged with two different EA processes those days. Those processes differ one from each other in many ways. There's one difference that I want to deal with and that's absents or existence of other architecture efforts.

Full post on IASA site.

New (for me) and intersting EA blog.

nattYGUR — Thu, 08 Dec 2005 19:39:00 GMT

John Wu's Enterprise Architecture blog:

http://www.e-cio.org/

Now I'm TOGAF certified (by The Open Group).

nattYGUR — Fri, 04 Nov 2005 19:46:00 GMT

After a course (interesting one) and a workbook I was infomed yesterday that I found qualified to be TOGAF certified. I think that course might be usfull for almost any kind of architects.