We need to think about the way components interact. Request/reply is the easiest but not always the best option. (Note that synchronous communication doesn't have to spell synchronous interaction; see for example, my post on EDA vs. Synchronous Request/Reply).
Posted by Arnon Rotem-Gal-Oz at 06:47 AM Permalink
|
March 22, 2007
Architects and Project Managers: Part 2
In a previous post, I introduced three questions in regard to Architects vs. Project Managers.
- How do we, as architects, know we cross the boundary between steering the project in the right technical direction to "destroying the developers joy of creation and professionalism"?
- Assuming this PM is right, what's the best way to defuse the situation?
- And in wider scope, how do you balance and divide the responsibilities between the project manager and the software architect?
In this post I examine the first question.
Having played both roles (architect and project/development manager) I have a wide perspective on the subject and still I'd have to say that there isn't one "line" that fits all situations. It depends on a few variables like the team's level of expertise, the project's size, the project's complexity etc.
There are few things to watch out though.
- You need to make sure that you are not a bottleneck. If "every" technical decision has to go your way and the project is not really small , then you have a problem. Projects usually have mixed skill set.
- There's more than one way to skin a cat -- and the way chosen doesn't have to be your way. As an architect your job is make sure it fits the architectural constraints/goals not to design the whole system. Note that developers are creative folks and also problem solvers -- usually they don't like micromanagement, including technical micromanagement. You should have a real reason to override the design.
- Always be ready to explain that reason. I have to admit that from time to time I do tend to a solution as a final and beyond discussion (nobody's perfect…), but at least when someone points that out, I take a step back and explain myself. I don't think that there is a line to cross here.
- If you see a developer who constantly produces bad designs, talk with the PM and try to make the time to mentor him. One good way to do that can be pair programming for awhile. If nothing helps you should let the PM handle that (maybe he need to be moved to another project, maybe fired altogether or maybe he just needs to get more training).
- Developers are more likely to accept the opinion of architects that are part of the team. Granted, this is not always possible but if it is, that's the preferred way.
- Sometimes "even" architects can be wrong (that's never happened to me, of course :-))
Posted by Arnon Rotem-Gal-Oz at 11:43 AM Permalink
|
March 20, 2007
IASA's IT Architect Skills Library Online
After several months of hard work, IASA, the International Association of Software Architect, has published online the Architect Skills Library. What is the Skills Library? Well, it is what you get when a few dozen architects (your humble servant included) write papers relating their experience on the different aspects of the architect’s role -- everything from design, infrastructure, and quality attributes to human dynamics (soft skills)
I should probably mention mention both Nicole Tedesco and Dana Gerow orchestrated all this effort, and without whom, I doubt if the project would now be online.
By the way, what is even more interesting is that IASA is organizing training material based on this body of collective knowledge. If this works well, we'll finally have a comprehensive course to train new architects. Meanwhile, you can find the all the PDFs online at http://www.iasahome.org/web/home/skillset
P.S.
As I mentioned earlier I also wrote a paper for this project, "Views and Viewpoints," which you can download directly from here .
Posted by Arnon Rotem-Gal-Oz at 04:04 AM Permalink
|
March 16, 2007
SOA Patterns: Service Firewall
While I am on the subject of SOA patterns, it is probably a good time to publish another one. This time it is a security pattern, which I call "Service Firewall".
The Service Firewall helps deal with malicious "service consumers" and protect the services from several types of attack including for example XDoS (XML Denial of Service), malicious content, preventing leaking private information from the service etc.
You can download the draft for the pattern from here .
Posted by Arnon Rotem-Gal-Oz at 05:21 AM Permalink
|
March 14, 2007
Architecture & Design World 2007
It is a little far into the future (July 24-27, 2007), but it seems Architecture & Design world is going to be a very interesting conference.
Here are few of the presentations I want to attend:
And many many others.
Of course, you may also want to check out the presentation I’ll be giving on SOA Patterns :)
P.S.: It seems there was a problem with the comments system (thanks Sandy for pointing that out), so I'll wait a few more days before commenting on the Architect vs. Project Manager dilemma.
Posted by Arnon Rotem-Gal-Oz at 06:06 AM Permalink
|
March 09, 2007
Patterns
While waiting for feedback on what you think about architects vs. project managers, I thought I'd talk a little about patterns.
Recall that I'm writing a book on SOA patterns. I was speaking with a friend who asked why did I choose to document the SOA solutions as patterns. I told him that patterns seems the natural way to do that, but when I thought about it a more I came up with something a more structured.
The main reasons I see for using patterns to describes describing solutions using patterns are:
- Patterns have a name. This may not sound like much, but you can use names to communicate what you're trying to do. If the patterns you are using are common (or common within the group you work with), then using this name can make your communication smoother.
- Patterns have context. We all know there's no silver bullet (right?), so documenting a solution is not enough -- you also need to say when it is applicable. When you document a solution template with a pattern you also explain where it can be used. It can get even better if you also document when not to use the pattern. Patterns are "good practices" not "best practices".
- Patterns have consequences. I've said before that the secret of great architects is that "it always depends". The trick is to know to analyze the trade-offs of the various options. When you document a solution as a pattern you also explain what does it mean to use this pattern and the implications or consequences of using it.
- Patterns are related. A single pattern is usually related to several other patterns. Some patterns can be alternatives other can be complimentary and sometimes other patterns are the opposite (but they solve well other issues). Having these relations documented to construct what is known as a "pattern language" can really be a boon. For instance, youcan look into complimentary patterns and combine them to create integrated solutions for bigger problems. Or you can weigh alternatives by considering the consequences and context of related patterns.
The downside of patterns is that when you have too many of them and locating one that fits your situation can be difficult. Grady Booch has almost 2000 of them cataloged on his site (registration required), but it is still hard to locate the one pattern you want.
The other thing is that patterns are difficult to write. I just took a look at the first drafts of some of my patterns (posted on-line) vs. the current drafts of the same patterns and I see how difficult it was, but at least it is also very rewarding :)
Posted by Arnon Rotem-Gal-Oz at 05:06 PM Permalink
|
March 07, 2007
Architects and Project Managers: Part 1
Scott Berkun runs mailing list on project managment. Each week there's a new topic whihc is discussed by the mailing list members. This week's topic touches the issue of architects and project managers:
I'm wondering how to behave when there is an architect that has "signing authority" on what the developer group does, and abuses that authority to go into micro-details, thereby both destroying the developers joy of creation and professionalism, since they are not allowed to learn on their own the consequences of their designs/choices.
The problem is he's (probably as usual for architects) very smart technically, not that much EQ-wise, and very important to the organization.
How do we keep the architect, but change his attitude?
This brings several interesting questions:
- How do we, as architects, know we cross the boundary between steering the project in the right technical direction to "destroying the developers joy of creation and professionalism"?
- Assuming this PM is right, what's the best way to defuse the situation?
- And in wider scope, how do you balance and divide the responsibilities between the project manager and the software architect?
I am interested in hearing what you have to say so I'll wait a few days and tell you my opinion next week. :-)
Posted by Arnon Rotem-Gal-Oz at 04:09 AM Permalink
|
March 03, 2007
Reuse in SOA
Following my post on SOA definition, Alex left the following comment:
One question -- how can an organization achieve "agility" through an SOA, if not through "re-use"? Isn't re-use really the ROI for implementing a Service?
The way I see it, Agility means the ability to change rapidly and it doesn’t have to mean reuse; for instance, it can come from the ability to replace a component without disturbing other dependent components, though you can say that this is reuse as you are reusing the interface (contract).
When you replace or update a service, you may reuse some or maybe even all of the previous version of a service -- as long as the context for that service didn’t change significantly -- if it did the granularity of the reusable components will be much smaller than a "service."
I would also note that I think there’s a difference between reuse and use. If you take the same ordering capabilities and you include it in two business processes that just using it. I’ve seen reuse of services in product companies where services were reused with few modifications between two or more solutions but this isn’t very common.
Regarding the ROI of SOA: That doesn’t have to be reuse or just reuse it is also things like easier connectivity so that you can integrate faster with partners or new components that are developed. Another way to measure ROI is measure the gains in easier replacability and adaptability so you can faster respond to changing business requirements (e.g., changing what counts as a VIP customer without letting any of the service’s consumers know that something changed).
Posted by Arnon Rotem-Gal-Oz at 03:15 PM Permalink
|
March 01, 2007
Software as a Service (SaaS)
Yup, here is another overload of the term "service", and as can be expected many people get it wrong and think that SaaS=SOA. Which of course it isn’t the case.
SaaS is about taking outsourcing to the next level. Instead of outsourcing the development of system why not outsource IT. SaaS is the new incarnation of Application Service Providers. In the previous round, we had someone who supplied the hardware and each subscribing company would have their own software running on the ASP’s machines. In this round, we are talking about more advances solutions where you have "multi-tenants" -- the same application can serve multiple companies while providing the necessary isolation, security, and customization.
Nicholas Carr with his (in?)famous paper IT Doesn’t Matter is probably one of the fathers of this approach. In this paper, Carr says that IT will not provide competitive edge as it used to for much long and it will become more and more like electricity -- a must, but not a strategic advantage. This is something that is already starting to happen. For instance, I know of a large company in the food industry here in Israel, which has a deal with hardware vendor where they get hardware much stronger than they would ever need and they pay by CPU consumption.
SaaS is taking this situation and extending it to software as well. And we aren’t talking about some distant future either -- it is already here. See for example Salesforce.com.
There are few applications where this can make sense. For instance, how different is your accounts payable from our's or their's? I think that ERP modules are a good candidate for SaaS as you have a very wide common denominator between different installations and they don’t really give you a competitive edge.
This can work pretty well for brick-and-mortar companies whose main business is not IT (to an extent; more on that later), but it won’t fly for companies where the IT is the business. For instance, I don’t see SaaS getting popular among banks or cellular companies.
Another aspect that would probably stay in-house even if SaaS would be popular (in my opinion) is Business Intelligence. I think while you may out source your operational data the trends and indexes you follow to make sure the business is on-track are still too strategic to entrust with someone else
What do you think?
[Editor's Note: For more on SaaS, see Software as a Service by David Dame. Also, take a look at the article in the April 2007 of Dr. Dobb's Journal entitled From SOA to SaaS by David Houlding. David shows how to grow a local SOA into a federated SOA distributed over the web to use and deliver SaaS. It will be posted on www.ddj.com shortly.]
Posted by Arnon Rotem-Gal-Oz at 01:16 AM Permalink
|
