If you have 5 minutes, you can get a reasonable idea about your personality type here:
http://www.haleonline.com/psychtest/index.php

I'm a strong INTP. Each of the four categories have two choices, so there are 2^4 = 16 different profiles or personality types (see graphic below). You'll fall into one of those sixteen and will pretty much be that for the rest of your life - that is who you are. While it can be useful to know your own type, it is probably more valuable to know that of your teammates and companions - and use it to leverage the strengths that each brings to the table.

Since each of the four categories defines a "preference", you'll probably find that you have some tendencies described by both choices. However, if you really think seriously and honestly thru the questions, you'll find one more strongly defines your comfort zone and/or typical mode of operation when given a choice and the freedom do as you please. Note that you might associate negative meaning to the descriptors: "introvert" and "judger". They don't mean shy and critical/mean in this context, so focus on the introspective questions in each category, rather than the one word descriptors.

For me, the E/I category was more of a toss up. But I'm a strong NTP. Scott McNealy and Albert Einstein are/were INTPs too. It turns out that most Architects fall into this profile type as well.. That's good, I guess, because I'm an IT Architect. The role and personality seem to match and I love what I do. But as I suggest below, diversity is healthy.

As an INTP, I tend to listen more than I talk, and then think before talking. I tend to look at the possibilities and big picture, and  then figure out how to get there in interesting and creative ways. I am fact/truth based and am concerned with efficiency and forward progress more so than sensitivity or political correctness. I enjoy coming up with creative solutions and starting the process (architecting) more than I enjoy closure (implementing). And along the way, the "NT" in me enjoys a good debate about the best approaches and the logic that supports the decisions.

However, one of the benefits of knowing your own "type" is to explore possible challenges and how others might help complete the team. An INTP often spends too much time talking/thinking about what can be, and can be light on filling in enough of the details. We tend to over think and analyze.. always considering new options and optimizations, sometimes not executing promptly against the time line as desired by an "SJ" type (eg: a Project Manager). A "P" types get their max adrenaline rush and surge of productivity when the drop dead time is at hand.... whereas the "J" type maps out a step-by-step plan and manages to that (fixed) schedule.

Clearly, there is an advantage to a team that consists of a diversity of types.

I just completed the first 1.5 hours of the Facilitated Mentoring program that initiates a mentor/mentee relationship at Sun. I'm the mentor. My mentee is an ISFJ - almost my polar opposite. This should be a rich/rewarding experience for both of us. I highly recommend it.

March 14, 2005 02:05 PM EST Permalink

I have the utmost respect for our CTO of Enterprise Web Services, John Crupi. He is a great guy and one of our sharpest arrows. If you get a chance to hear him speak, you will enjoy the time and take away valuable insights. John recently joined the BSC community (blogs.sun.com) and posted a brief intro to SOA. Welcome John! I look forward to future updates on this topic on your blog.

Me, I'm a Lead Architect with a background built on consulting and systems engineering primarily at the IT Infrastructure level, focused on most of the solution stack - up to but not generally into the functional business logic or S/W app design space. Prior to Sun I spent years as a programmer translating business requirements into S/W solutions... but that's been a while.

With that context (the fact that I come to the table with certain biases and experiences that color my perceptions, and I suspect John does as well, to some degree) I'm going to suggest that maybe John is slightly off-base w.r.t. his premise about SOA and IT / Business Unit (BU) alignment. In the spirit of extracting deeper insights and clarifying positions, I'm going to challenge John with an alternate view (a debate), and ask him to either agree with me or defend his position. Hmmm...is this a Career Limiting Move - publicly challenging one of our Chief Technology Officers? No... not at Sun. We encourage our folks to question assumptions and even our leaders, resolve/align, and then move forward in unity. Okay, with that:

John, you suggest that: one of the critical success factors for SOA is a tighter relationship/alignment between Business Units and IT. In fact you say we can not even do SOA without effort on the part of the Business Unit.

Now I could not agree more that Business/IT alignment is absolutely paramount. The lack of business focus and alignment is one of the top reasons why so many IT initiatives fail to deliver or meet expectations or provide a higher return to the business than its cost. I've blogged about that very topic.

However, that alignment, IMHO, is not related to SOA. In fact, I believe there are benefits to isolating service construction techniques from the consumers and owners of those services. To reuse the power utility metaphor:

You don't care how S&L built the power plants that deliver your electric service, or how power distribution provisioning logic taps into multiple grid suppliers and peak-load gas turbines. You simply have specific service level and financial demands, and expect a quality experience when/if you have to interact with the service desk to resolve a dispute, request a change in your service, or report an incident.

There are two primary components to IT... the design/development of services, and the opertaion/delivery of services.

"Business - IT Development" alignment is driven by business requirements (functional, service level, cost, time-to-market, etc). SOA isn't a "requirement", but a technique that helps IT achieve the desires of the business to support their business processes.

"Business/IT Operations" alignment is properly performed as defined by ITSM/ITIL Best Practices, and as illustrated in my graphic below. Business and IT need to work as a intimate partnership to define, implement, deliver, and continually refine an optimized Service Portfolio at contracted service levels and an established and predictable cost point. Again, SOA is simply a technique that helps IT achieve operational excellence.

All other functions are internal to IT. The fact that requirements are fleshed out in an Agile fashion and constructed/deployed using a SOA strategy is meaningless to the Business Unit. They simply want IT to build the capability they need, adjust it when asked, and deliver it as expected.

As a consumer and purchaser of various utilities (electricity, gas, cable, phone, water, etc) you don't need nor want to know the details of how the utility achieves scale economy or service resiliency or security or efficiency/utilization or adaptability or regulatory compliance. Well, okay, you and I by nature might be curious and like to know how these things work. But, in general, exposing the internal details of how a Service Delivery Platform is constructed is, IMHO, counter-productive to the Business/IT conversation and partnership. Some curious BU stakeholders will likely want to understand and even attempt to influence your model (eg: buy EMC, use .NET, etc). But that kind of inquiry can expose dysfunction and introduce inefficiency in the model. You don't tell Pacific Power to buy GE turbines or supply power at 62 hertz, unless you want to pay extraordinary fees for your own custom power plant.

I strongly believe in the principles of Agile development and architecture. Clearly the days of throwing a fixed requirements document over the wall are over. Business Units, IT Operations, and IT Development all must work together in a healthy partnership focused on continuous business process optimization and refinement. However, in my opinion, the true value of SOA is in the benefits it delivers to the internal IT function w.r.t. scale economy, resiliency, efficiency, adaptability, etc. Business Units don't need nor want to know about SOA... they simply have (frequently changing) requirements and expectations.

Bottom line: SOA is a architectural style/technique that IT Shops will employ to quickly respond to changing service level demands, while operating IT as an efficient adaptable business with an ability to tap into (integrate with) external/outsourced partners (blog on Coase's Law).

John - I respectfully invite a reply.

March 14, 2005 07:25 AM EST Permalink

Disclaimer: I've consulted at all but one of these firms, and can tell you that this puzzle's solution does not generally describe actual purchase decisions or deployment standards at these firms. It's just a puzzle.

Your job is to figure out each firm's preferred choice of servers and storage.

1. WalMart, the firm using SGI servers, and the firm with Hitachi storage, are all market leaders.
2. Newsflash: CNN uses IBM servers for their back-end processing.
3. Neither AT&T nor Disney have any AMCC storage in their data centers.
4. The firm still using SGI uses neither NetApp nor EMC storage.
5. Hitachi and NetApp were eclipsed on the Sun shop's preferred storage vendor list.
   
6. Both WalMart and Google have kicked EMC out of their centers.
7. Disney did not entertain the proposal to start using Fujitsu servers.
8. A search of Google's operations shows no sign of HP or SGI.
9. A Disney "balance-of-trade" agreement left LSI Logic without a ticket.
10. The firm using Fujitsu servers does not permit NetApp based storage in production.
11. Google is just starting to consider bringing in Hitachi storage arrays.

The following graphic is NOT the solution, just a randomly ordered list of related logos. It provides no useful information beyond the statements above (I just like to include a graphic with each puzzle). Good luck.

March 14, 2005 07:20 AM EST Permalink