In many software organizations, there are job titles like
"Software Architect". What do Software Architects do? That's a great
question, but there is no general agreement on the answer.
I have a friend who is a "real" architect (the kind that designs and
builds buildings) and he tells me that in his industry they are a bit
upset with our industry's use of the term. It's mostly because
Software Architects don't go through anything like the kind of
training, testing, and certification that building architects do. I
think they have a good point.
A recent article by Joe Winchester in the online edition of Java
Developers Journal entitled, "Those Who Can, Code; Those Who Can't,
Architect" really got my attention. The article begins with this:
"At the moment there seems to be an extremely unhealthy obsession in
software with the concept of architecture. A colleague of mine, a
recent graduate, told me he wished to become a software architect. He
was drawn to the glamour of being able to come up with grandiose ideas
- sweeping generalized designs, creating presentations to audiences of
acronym addicts, writing esoteric academic papers, speaking at
conferences attended by headless engineers on company expense accounts
hungrily seeking out this year's grail, and creating e-mails with huge
cc lists from people whose signature footer is more interesting than
the content. I tried to re-orient him into actually doing some coding,
to join a team that has a good product and keen users both of whom are
pushing requirements forward, to no avail. Somehow the lure of being
an architecture astronaut was too strong and I lost him to the dark
side."
Of course, there's a "Software Architect" article in Wikipedia, so I
checked it out. The job description seemed to have a lot to do with
working with stakeholders, getting user requirements, doing cost/benefit
analysis, generating acceptance test requirements, and "generating
products such as sketches, formal diagrams, executable models, an
early user's manual, and prototypes." Except for maybe prototypes,
that doesn't sound like much codin' to me! Where is the need to
actually understand programming?
Winchester continues: "Meanwhile, the architects seem invincible
to failure and rise within the ranks of their organizations, ordering
fresh business cards each year with the words 'architect,' 'senior'
or, for the power blowhards, 'distinguished' in the title. They are
drawn to the tar pit of attending and creating presentations, or
joining conference calls with fellow architects who showboat their
knowledge of obscure standards specifications or bleeding-edge
research projects."
I found that there's an organization called the "Worldwide Institute
of Software Architects (WWISA)". Ironically, the graphic on their web
site's home page illustrates that they do in fact consider themselves
architects in the same sense as the kind who build buildings.
Winchester concludes: "When confronted by such people, recant the
following mantra:
Code ships,
code runs,
code helps users,
get their job done.
Remind any architects in your path that presentation charts, e-mails,
project plans, line-items spreadsheets and so forth, are all there to
help the code ship on time and to spec. The goal of everyone on a
project should be to spend as little time as possible on tasks that
distract from the job of creating quality, tested, and shippable
code. Please architects, please understand this, respect this, and
quietly stay out of the way of those good folk who prefer to spend
their day working with an IDE writing code rather than composing
e-mails."
J.A.W.
Saturday, March 17, 2007
Is Python Ready for Prime Time? Yes!
Is Python Ready for Prime Time?
In the 5 March 2007 issue of eWeek, there is a great article entitled, "Python slithers into systems." It's good news for any software developers who are told by their management that Python isn't "enterprisey" enough for serious applications that should really be written in Java, C++, or C.
The article is about a project at ITA, a Cambridge, MA producer of airline IT software and services. ITA is replacing Air Canada's reservation management system with a new one written primarily in Python. The old system runs on a mainframe, and the new system will be hosted on a farm of Linux PCs.
Dan Kelly, Director of Application Integration at ITA said, "in addition to being a huge technical challenge, nobody in the history of airline computing has ever swapped out a mainframe-based reservation system for something else, that's the scary thing for us. Sometime in the next year Air Canada is going to turn off for a few hours, and then we're going to turn back on [using] the new system. That type of thing has never been done—going from a legacy system to a new system."
Regarding the skepticism that dynamic languages like Python may not be up to the task, the article states, "Much of the code ITA employs is written in Python, despite skepticism by some that dynamic languages are not ready for prime time. However, people such as Guido van Rossum, the creator of Python, point to the successful use of the language at places such as Google and YouTube, which endure enterprise-scale traffic on a daily basis. Meanwhile, ITA has about 200,000 lines of Python code in use in its production software."
The new system is mostly written in Python, but not exclusively: "There are components written in Java, LISP, C++ and Python. For each component area, we got a functional spec from the customer saying it has to do X, and we had to figure out who the right people were to work on that project, and those people decide what implementation language to use," Kelly said. He continues, "But it's just coming into its own where you could defend it to nontechnical people as a language on which you could develop enterprise software. One of the things we have going for us is, because we're founded by computer scientists, we don't have to defend our use of that programming language because it's not Java. We have a wonderful ability here to choose the right tool for the job. We have components that are written in Java, in C++, in Python, and Ruby and Perl. [Python is] definitely viewed internally here by some of the best computer scientists in the world, people from MIT's AI [artificial intelligence] and CS [computer science] labs, as enterprise worthy."
Concerning hiring developers, Kelly said when ITA hires new people, they like to hire those with Python experience "because we've had a lot of luck with Python people having a lot of core problem-solving and system-building ability. He said it is pretty easy to find Java or C programmers who are good at line coding but not generally good at problem solving. 'It's much more unusual for us to find people who can analyze a problem domain and then implement a solution where they cross a bunch of problem domains. Python developers typically can.'"
A futher note about the use of the term "enterprise" from the article: "Adrian Holovaty, a developer at Washingtonpost.com and the creator of Django, a Python Web development framework, bristles at the criticism of Python as possibly not being ready for the enterprise. 'The word enterprise in this context is mostly meaningless to me,' said Holovaty in Chicago. 'It's really just a marketing word that has no basis in logic.'"
Memo to managers: trust the developers.
J.A.W.
In the 5 March 2007 issue of eWeek, there is a great article entitled, "Python slithers into systems." It's good news for any software developers who are told by their management that Python isn't "enterprisey" enough for serious applications that should really be written in Java, C++, or C.
The article is about a project at ITA, a Cambridge, MA producer of airline IT software and services. ITA is replacing Air Canada's reservation management system with a new one written primarily in Python. The old system runs on a mainframe, and the new system will be hosted on a farm of Linux PCs.
Dan Kelly, Director of Application Integration at ITA said, "in addition to being a huge technical challenge, nobody in the history of airline computing has ever swapped out a mainframe-based reservation system for something else, that's the scary thing for us. Sometime in the next year Air Canada is going to turn off for a few hours, and then we're going to turn back on [using] the new system. That type of thing has never been done—going from a legacy system to a new system."
Regarding the skepticism that dynamic languages like Python may not be up to the task, the article states, "Much of the code ITA employs is written in Python, despite skepticism by some that dynamic languages are not ready for prime time. However, people such as Guido van Rossum, the creator of Python, point to the successful use of the language at places such as Google and YouTube, which endure enterprise-scale traffic on a daily basis. Meanwhile, ITA has about 200,000 lines of Python code in use in its production software."
The new system is mostly written in Python, but not exclusively: "There are components written in Java, LISP, C++ and Python. For each component area, we got a functional spec from the customer saying it has to do X, and we had to figure out who the right people were to work on that project, and those people decide what implementation language to use," Kelly said. He continues, "But it's just coming into its own where you could defend it to nontechnical people as a language on which you could develop enterprise software. One of the things we have going for us is, because we're founded by computer scientists, we don't have to defend our use of that programming language because it's not Java. We have a wonderful ability here to choose the right tool for the job. We have components that are written in Java, in C++, in Python, and Ruby and Perl. [Python is] definitely viewed internally here by some of the best computer scientists in the world, people from MIT's AI [artificial intelligence] and CS [computer science] labs, as enterprise worthy."
Concerning hiring developers, Kelly said when ITA hires new people, they like to hire those with Python experience "because we've had a lot of luck with Python people having a lot of core problem-solving and system-building ability. He said it is pretty easy to find Java or C programmers who are good at line coding but not generally good at problem solving. 'It's much more unusual for us to find people who can analyze a problem domain and then implement a solution where they cross a bunch of problem domains. Python developers typically can.'"
A futher note about the use of the term "enterprise" from the article: "Adrian Holovaty, a developer at Washingtonpost.com and the creator of Django, a Python Web development framework, bristles at the criticism of Python as possibly not being ready for the enterprise. 'The word enterprise in this context is mostly meaningless to me,' said Holovaty in Chicago. 'It's really just a marketing word that has no basis in logic.'"
Memo to managers: trust the developers.
J.A.W.
Early signs of the death of SOA?
Trying to follow what's going on in the world of enterprise
and web application architecture is guaranteed to make your head
spin. Much of the controversy centers around the SOA vs. REST
debate. Without going too far out on a limb myself, here's an
(imperfect and imprecise) summary of the debate:
SOA (Service-Oriented Architecture) generally means using SOAP
and the myriad related WS-* specifications. Interactions between
clients and servers are accomplished by using Web Services
standards including XML, SOAP, WSDL, and UDDI.
REST (Representational State Transfer) views the web as comprised
of resources, all identified by URLs. Referred to by some as
"ROA" (Resource-Oriented Architecture). REST is an architectural
style, based on standards such as HTTP, URL, HTML, XML, and MIME
types.
I like this quote from Stefan Tilkov that I found in a comment at
http://www.infoq.com/articles/sanjiva-rest-myths: "SOA as a
business concept can be implemented using WS-* or REST - both
(and many others) are valid strategies. Others view SOA and ROA
as alternatives, with WS-* being an implementation of SOA, and
RESTful HTTP an implementation of ROA. That view is valid as
well."
SOA advocates tend to argue that the SOAP/WS-* specifications
make it easy to build an interoperable, standards-compliant
service-oriented architecture, and that REST is just a bunch of
technologies, not an architecture.
REST advocates tend to argue that the richness of the full HTTP
specification itself gives us all we need to build robust web
applications, and that SOAP/WS-* is too "Enterprisey", too
complicated, designed to make the vendors rich, and just not
needed for many purposes.
Anyway, the main reason I decided to write this article was
because of a paper I came across, written by Nick Gall, a VP at
Gartner. Mr. Gall's paper was submitted in response to a call for
papers for a workshop held on 27-28 February 2007, organized by
the World Wide Web Consortium (W3C) on "Web of Services for
Enterprise Computing", the aim of which was "to gather interested
parties to discuss and provide recommendations to W3C regarding
the best approaches to facilitate the processing of business
transactions and interactions with systems that pre-date the Web,
and address the need to interconnect intranet and/or extranet
services using Web technologies."
Mr. Gall's paper states the problem as "Web Services based on
SOAP and WSDL are "Web" in name only. In fact, they are a
hostile overlay of the Web based on traditional enterprise
middleware architectural styles that has fallen far short of
expectations over the past decade." His solution summary is
stated as "The W3C should leave the work on standardizing the
WS-* middleware architecture to the middleware vendors and shift
its focus to standardizing aspects of Web architecture that make
it easier to apply to "application to application" scenarios."
His conclusion states "that the W3C should extricate itself from
further direct work on SOAP, WDSL, or any other WS-*
specifications and redirect its resources into evangelizing and
standardizing identifiers, formats, and protocols that exemplify
Web architectural principles. This includes educating enterprise
application architects how to design 'applications’ that are
'native’ web applications."
I'm not sure how the workshop went, or if anything much was
accomplished, but to me it is pretty amazing that a top
representative of the Gartner consulting firm is basically saying
SOA is wrong, and telling the W3C to get out of (run away from!)
the SOA debate.
I guess we'll have to just wait and see how this all turns out.
For now, I'm betting on REST.
More articles on the SOA vs. REST debate can be found at
http://www.infoq.com/REST;jsessionid=9E7BF20CB5812F0C56B0434A97A166E3
J.A.W.
and web application architecture is guaranteed to make your head
spin. Much of the controversy centers around the SOA vs. REST
debate. Without going too far out on a limb myself, here's an
(imperfect and imprecise) summary of the debate:
SOA (Service-Oriented Architecture) generally means using SOAP
and the myriad related WS-* specifications. Interactions between
clients and servers are accomplished by using Web Services
standards including XML, SOAP, WSDL, and UDDI.
REST (Representational State Transfer) views the web as comprised
of resources, all identified by URLs. Referred to by some as
"ROA" (Resource-Oriented Architecture). REST is an architectural
style, based on standards such as HTTP, URL, HTML, XML, and MIME
types.
I like this quote from Stefan Tilkov that I found in a comment at
http://www.infoq.com/articles/sanjiva-rest-myths: "SOA as a
business concept can be implemented using WS-* or REST - both
(and many others) are valid strategies. Others view SOA and ROA
as alternatives, with WS-* being an implementation of SOA, and
RESTful HTTP an implementation of ROA. That view is valid as
well."
SOA advocates tend to argue that the SOAP/WS-* specifications
make it easy to build an interoperable, standards-compliant
service-oriented architecture, and that REST is just a bunch of
technologies, not an architecture.
REST advocates tend to argue that the richness of the full HTTP
specification itself gives us all we need to build robust web
applications, and that SOAP/WS-* is too "Enterprisey", too
complicated, designed to make the vendors rich, and just not
needed for many purposes.
Anyway, the main reason I decided to write this article was
because of a paper I came across, written by Nick Gall, a VP at
Gartner. Mr. Gall's paper was submitted in response to a call for
papers for a workshop held on 27-28 February 2007, organized by
the World Wide Web Consortium (W3C) on "Web of Services for
Enterprise Computing", the aim of which was "to gather interested
parties to discuss and provide recommendations to W3C regarding
the best approaches to facilitate the processing of business
transactions and interactions with systems that pre-date the Web,
and address the need to interconnect intranet and/or extranet
services using Web technologies."
Mr. Gall's paper states the problem as "Web Services based on
SOAP and WSDL are "Web" in name only. In fact, they are a
hostile overlay of the Web based on traditional enterprise
middleware architectural styles that has fallen far short of
expectations over the past decade." His solution summary is
stated as "The W3C should leave the work on standardizing the
WS-* middleware architecture to the middleware vendors and shift
its focus to standardizing aspects of Web architecture that make
it easier to apply to "application to application" scenarios."
His conclusion states "that the W3C should extricate itself from
further direct work on SOAP, WDSL, or any other WS-*
specifications and redirect its resources into evangelizing and
standardizing identifiers, formats, and protocols that exemplify
Web architectural principles. This includes educating enterprise
application architects how to design 'applications’ that are
'native’ web applications."
I'm not sure how the workshop went, or if anything much was
accomplished, but to me it is pretty amazing that a top
representative of the Gartner consulting firm is basically saying
SOA is wrong, and telling the W3C to get out of (run away from!)
the SOA debate.
I guess we'll have to just wait and see how this all turns out.
For now, I'm betting on REST.
More articles on the SOA vs. REST debate can be found at
http://www.infoq.com/REST;jsessionid=9E7BF20CB5812F0C56B0434A97A166E3
J.A.W.
Hilarious SOA Video
I found an absolutely hilarious video on YouTube (what a surprise!) called "Greg the Architect - SOA This. SOA That." Not only funny, it reflects a strangely ironic, true picture of the state of the current Service-Oriented Architecture
(SOA) craze.
See for yourself at http://www.youtube.com/watch?v=uOQcjvUHZ0k
The video was apparently produced for an online magazine:
http://www.SOANowJournal.com
J.A.W.
(SOA) craze.
See for yourself at http://www.youtube.com/watch?v=uOQcjvUHZ0k
The video was apparently produced for an online magazine:
http://www.SOANowJournal.com
J.A.W.
Subscribe to:
Posts (Atom)