e martë Jan 03, 2006

SOA and Kitchen Renovation

SOA and Kitchen Renovation We're in the process of renovating our kitchen.  In our kitchen design, we're actually constructing a new structure to extend the current kitchen. If any of you have gone through this, I'm sure you have lots of war stories. But, as my wife and I go through this process,  I keep seeing similarities between renovating a kitchen and building a SOA.  To understand what I'm talking about,  I'll start by making some role comparisons:

Kitchen Renovation Roles
SOA Roles
Home Owner Business Manager
Kitchen Designer Business Analyst
Building Architect
SOA Architect
Construction Crew
Development Team

When renovating a kitchen there are usually four key roles; home owner, kitchen designer, architect and construction crew. In SOA, there are similar key roles; business manager, business analyst, SOA architect and development team. These four roles tend to have similar responsibilities as shown below.

Renovation Roles Renovation Responsibilities SOA Roles
SOA Responsibilities
Home Owner Overall requirements and budget Business Manager Overall requirements and budget
Kitchen Designer Kitchen requirements and design Business Analyst Business requirements and features
Building Architect Overall architecture
SOA Architect Overall architecture
Construction Team
Project construction
Development Team
Project implementation

The most important person in a kitchen renovation is the home owner. In SOA, the most important person is the business owner, who is usually the business manager.  Essentially, it's who owns the budget and writes the check.

You can renovate a kitchen without a kitchen designer, but I don't recommend it. Kitchen designers have the best  understanding of the requirements and features of a kitchen. Even building architects will tell you to bring in a kitchen designer to insure good flow, appliance placement, cabinetry, flooring, zoning, etc.

Similar to a kitchen designer is the SOA business analyst. Just as you can renovate a kitchen without a designer, you can build a SOA without a business analyst.  But, I also don't recommend this. The business analyst understands the business and business requirements and acts as a liaison between the SOA architect and the business unit. It's the business analyst who translates business requirements into information to help the SOA architect design the system. Kitchen designers tend to act as a liaison between the home owner and the building architect. Just like the business analyst is driven by the business unit has to support the business objectives, the kitchen designer supports the home owner's objectives.

Then there's the building architect who is core to the overall kitchen design. He/she is the one who has to take all the requirements of the kitchen designer and the home owner and turn that vision into a set of architectural blueprints. These blueprints are used for permits, cabinet sizing/layout, construction cost estimates and eventually become the master construction plans. If the blueprints are wrong or incomplete it trickles down to all levels and eventually ends up costing the home owner much, much more.

Finally, there's the kitchen construction team. The construction company bids on a project based on the complexity of implementing the blueprints, material and labor costs and a slew of other cost factors. You can probably imagine what can and will possibly go wrong in this model if all parties aren't aligned. If the homeowner changes the requirements mid-stream, change order costs incur. If the kitchen designer mis-calculates the cabinet dimensions and the cabinets don't fit, it delays the overall schedule, which translates to added costs. You get the idea. So much can go wrong if all stakeholders are not in complete sync in both the kitchen renovation and SOA world.



e enjte Dhj 08, 2005

Cool Java Persistence Code Generator

Firestorm
For all of you who are constantly writing and debugging your persistence code, have I got a tool for you.

Check out Firestorm.

Firestorm can reverse engineer just about any database out there and generate Core J2EE Pattern compliant DAO,  JDO and Hibernate code. The latest version even supports Dynamic Inserts.

Here's a blurb from their web site:

"FireStorm/DAO adopts a pragmatic approach of generating Java source code for data persistence that is a direct mapping of a particular relational database schema. It is also possible to define complex multi-table queries and to leverage existing database logic contained within stored procedures."

This is a very cool tool.

Check it out!

e enjte Gsh 04, 2005

Rethinking your Business around SOA


I think companies are starting to see the amazing impact SOA can have on their overall business value proposition.

Think about Amazon.com. Most people would say that Amazon.com is a site to buy lots of products. In their mind,  Amazon.com's website and Amazon.com the company are the same. But, Amazon doesn't appear to see it that way....

As an Amazon outsider (which means I'm hypothesizing to make a point), I bet it went something like this:

Amazon.com, the beginning:
    \* Business Unit: Leverage this thing called the Internet and create a website to sell books to the world. Make tons of money. Build an easy-to-use website so people of all ages can buy books. Track their buying patterns and let them rate the books so others can see.

    \* IT: Ok, we can build an awesome, intuitive web site and a commerce engine to support it.

So, basically, Amazon.com the website and Amazon.com the commerce engine were one. In other words, the commerce engine needed to support one channel; the Amazon.com website.

But, as time went on, the smart people at Amazon.com started recognizing the web services potential. They provided REST and SOAP apis so developers/companies could access their services outside of the Amazon.com website. Developers liked this and were amazed at the simplicity and power in being able to access Amazon.com's powerful commerce engine. But, there was something else happening.

A few years ago I did a search for a product on Amazon.com and it showed me the same product from partners at a lower cost than Amazon.com was offering. I thought I found a bug and tried it again. Same thing happened. Amazon.com was revealing partner products at lower prices on the same page as their higher price. From the periphery, this made little business sense. But, thinking about it, it become genius.

It looked like Amazon.com had begun treating Amazon.com the website and its partners as close equivalents. But,  more importantly, if Amazon.com's  commerce engine was actually separated  from Amazon.com the website, then it sounds like their business model changes from selling products on Amazon.com, to generating revenue from their commerce engine. And this is my point and the value SOA can bring to radically (and rapidly) change a business. You can already see this happening at eBay and Google.

Think about this. What if AOL didn't have a web presence anymore, but offered (probably) the world's largest digital asset management system (picture, video, music, etc) as services so others could build business on them. Sounds like a SOA opportunity to me. Why didn't AOL build the worlds best digital picture SOA for others to build a business. If they had, Snapfish, Ofoto (now Kodak Gallery), etc could have built their business on it and AOL would have reaped big rewards.

Is WebEx a web-based meeting company or do they provide a web-based meeting infrastructure. WebEx just opened their APIs  as web services and already companies are sprouting up which run on the WebEx services. Wait until ISVs start picking up on the fact that everyone needs web-based communication within their applications. Are they going to build their own or access WebEx's services. In the future, I predict WebEx makes more money on it's SOA communication services than the actual WebEx brand offering.

I want to finish up with a graphic of what I think will be the way we think about how SOA can open up new and amazing business opportunities. Not just for existing companies, but new companies which build on these services. I like to call this new type of company, the Composite Company. Imagine the opportunity when companies such as AOL, Google, eBay, etc all open up their services and have a uniform identity scheme. The types of Composite Companies who aggregate and provide a service on top of these rich services will provide services not available today.  It's mind-boggling to think what will happen when businesses provide SOA services as their core competency and Composite Companies begin to arrive.

CompositeCompany



e enjte Qer 16, 2005

SOA Best Practice for Business Unit Alignment

Best Practice SOA with Business Unit Here's probably the first best practice you should put into place when building a SOA:

Build a SOA with the business unit!

Here's what I mean. I keep seeing IT groups defining and building a SOA without engaging the business unit. Who, by the way, is their customer.  An example is an IT group building a SOA common services infrastructure (management, registry, policy, etc) as a set of services for the business unit to run their applications. But, they are building it without the business unit. Which leads me to:

Build a SOA without the business unit and watch them \*not\* come!

Seems so obvious, but it really isn't. IT groups have grandiose plans as to what infrastructure services they will provide and build  without even really knowing what the business unit needs. Why build 101 management features into the management service if the initial business unit application only needs 3.

Don't get caught in this trap. Get the business unit involved from the start and build the services based on their requirements. And most importantly:

Build the SOA incrementally!

e martë Pri 26, 2005

SOA, the Rock Star

SOA the Rock Star
Just finished the California leg of the U2 tour with Mary and Danny. That's right, the U2 tour! Unbelievably, the  TED prize granted Bono three wishes and we (Sun) are delivering on one of the wishes. The wish is: Bono wants to utilize technology to enlist his fans into his army against AIDS and poverty.  You can check out the video on One.org

So, driven by Mary, with Danny as the technical lead, we built a SMS solution for Bono to enlist his fans into the ONE Campaign during the Vertigo tour. We built a really cool SOA infrastructure to support the SMS solution. It's made up of a series of loosely coupled services all centered around consuming SMS messages and displaying the fan names on the screen during the concert.

Below is a pix of the Sun team on stage with Bono and Brad Pitt during a recent press conference.
One.org Press Conference


e martë Pri 19, 2005

SOA Service Granularity

Interestingly, one of the most debated SOA architectural aspects  (at least in architecture and development teams) is the granularity of a SOA Service. In the past year, I've tried a few different strategies with customers and fellow architects to describe the appropriate SOA service granularity. I started out saying "a SOA service must be coarse grained". "How large grained?", many would ask. "Very coarse grained", I would answer. Then I would say; "definitely not fine grained".

As you can see, this is a pretty poor definition. So, I thought about it and discussed it with Danny Malks and tried to make it more SOA-like. So, I started talking more about SOA services as  business services and thus having business service granularity. Sounds a bit subtle, but has a strong intent. As I mentioned in a prior blog, we want SOA to take a top-down (problem to architecture to solution) approach. This means that the business unit (user) drives the requirements and essentially (but, not directly) the service granularity. So, one way to think about a  SOA business service is to be able to put it in business speak. For example, we may talk about the  Insurance Quote Service and Inventory Service. We can talk to business people about services using this granularity and not get into tech speak. Notice that we refer to the services as nouns, not verbs. I've seen many services defined by a verb, such as Add Employee Service. Focusing on the actions (verbs) rather than the service (nouns) creates fine grained services and should be avoided.
CoarseGrainedServices


e shtunë Mar 19, 2005

SOA is a Business-Driven Architectural Style

SOA Shift #2 A few days ago, Dave Brillhart commented on my earlier blog on the SOA Shift for aligning IT and the business unit. This is a response/explanation to my thinking...

So what's the big deal with making the business unit so prominent when talking about SOA. It's not about being one big happy family.  It's about the organizational structure which needs to support what we really want to do; have business drive the requirements for SOA. That's what we mean when we say SOA is a business-driven architecture, not a IT driven architecture.  If the business unit and the IT team don't work together to achieve a SOA, you will be very hard pressed to get the requirements necessary to drive the proper service granularity and process definitions.

What does this really mean? It means that for SOA to be successful, it must be a "top-down" approach. And top-down, means problem to architecture to solution. It does not mean, working from what we have and just wrapping it with new technologies just because we can. This bottom-up approach is quite natural and easy and is the perfect recipe for a SOA failure.

This isn't just me thinking aloud. This is based on many discussions with customers citing why their initial attempts to use webservices and create SOA solutions failed. Many of our customers cite the "just wrap it in a web service" approach as a simple and natural way to create a the SOA service layer.  So simple (from a tools perspective), and natural (wrap what's there),  they thought it was worth a try. The problem, is taking an existing asset/system and making it a web service is a completely bottom-up approach and creates an immediate mismatch between the new web service interaction style and the existing system.  More about this in future blogs.,,

Below is a page from one of my presentations to help visualize these thoughts.

WrapAndReuse

e diel Mar 13, 2005

My Most Important Cell Phone Feature

Gesture Muting Gesture Muting

One of my favorite comics is the one where two dogs are sitting at the computer and the tag line reads "On the Internet, no one knows you're a dog."  But, I think we need a comic relevant to "generation flex" who like the flexibility of working from anywhere and doing conference calls at home, in the car, on the treadmill, while feeding the kids, going to the bathroom and even while changing poopie diapers. Not that I do any of these ;>, but I know others do. How? I can hear them. How can I hear them? Because, today's cell phone mute button technology sucks! That's right, let's start innovating in the least addressed feature of the cell phone; the mute button.

I have a nokia 82xx phone and it requires me to press a button, toggle down to "mute" and then select it. That's three steps! Plus, pressing a button is not conducive to how we mute. We mute out of necessity and we mute quickly and often. Pressing a button, let alone one which requires three steps is all wrong. So, here is what I propose: Gesture-based cellphone muting. Here's a few ideas:


1. The High-speed Wave gesture:
High speed wave

Basically, I wave the phone to the right and then to the left and it goes to mute.  I reverse the process to turn off mute. Note: this is best suited for headsets and not hand-holders.

2. The Pressure gesture:

Squeeze it
This method works for both headsets and hand-holders. Very simply, you squeeze the phone to place it in mute. You press again to turn off mute. This works best for the headset-ers who hold the phone. Of course, there is a pleasant audible to tell you if you're in mute mode.

3. The Scream gesture:

Scream
This is my favorite and very consistent with what happens right before you need to mute.  Your daughter walks in the room and says; "Daddy, mommy says you need to stop working or she's leaving you...". Since, this is not something new and you know its dinner time, your 6th sense detects  your daughter coming and right before she says a word, you yell out; "MUTE!". Instantly, your phone goes into mute mode. Maybe you can program in something better than "MUTE", such as "LOVE", "YOU LOOK GREAT", "I DON'T DESERVE YOU" or  "HAVE YOU LOST WEIGHT". Your choice, but any of these will have the same muting effect, but can also help relationships at the same time. I'd call this a double win!

Hopefully, someone from Motorola, Nokia or Ericsson will read this blog and grant my wish. If you have other ideas, please comment!


e premte Mar 11, 2005

SOA Shifts



SOA means a lot of things to a lot of people. And, now that the money is flowing to SOA, even more of us are interested. The reality is that SOA is much more than just a buzzword. It is an architectural style which tends to be best realized using Web Service and open standards. It's not the only way to implement SOA, but sure does seem to be the most popular lately.

We're finding that there are some key "shifts" that have to take place in an organization to be successful with SOA. Today, I'll talk about the first of these "SOA Shifts".

  • Shift #1 - SOA requires a combined effort between IT and the Business Unit
IT, BU - Peace be with you

The point of this shift is that we cannot do SOA without a mutual effort between IT and the BU. Gone are the days of throwing the requirements over the fence and hoping it hits. Not only do these two groups have to work together, they have distinct roles and responsibilities. Basically, the BU runs the show and owns the business drivers, use-cases and processes. IT implements the BU requirements and owns the service definitions.  It's unfortunate that we really do have to refer to this as a "shift", because we should be doing this anyway. But, the reality is that IT and BU typical function as disparate groups and rarely work together to have the business use-cases drive the process and service definition. More about this later, but if you get the gist of this shift, I think we can begin the journey to SOA....


e premte Shk 25, 2005

My First Day at Blog School


Hi all, my name is John Crupi and I am the CTO of the Enterprise Web Service Practice at Sun Microsystems. And, this is my very first blog.

This is very timely because today, Sun just announced a great joint partnership between Sun, data.org and Bono from U2. Press Release
This is turning out to be one of the most gratifying things I've done at Sun.

So, here are my interests which I'll be blogging about in the future:

1. Patterns - Bringing patterns to the next level... Core J2EE Patterns

2. SOA - Service Oriented Architecture isn't just a buzz word, it really has potential to change the way we do integration (in an open standard way)...

3. Cool tech stuff - Things which make my life easier...

4. University of Maryland Terps - Big sports fan... UM Terps

5. Electronic drumming - What I really wish I got paid to do... Roland V-Drums

6. Anything else which may seem interesting (at least to me)...

Looking forward to this... jc

About

crupi

Search

Categories
Archives
« prill 2014
DieHënMarMërEnjPreSht
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today