Contribution 54 - Revision history

Balesd: Removing all content from page

2008-07-14T22:18:37Z

Removing all content from page

←Older revision		Revision as of 22:18, 14 July 2008
Line 1:		Line 1:
-	==There are no technical problems, only people problems==

-	As a software architect, you must play the role of client advocate. Your primary mission is the see your client’s vision through to fruition. A project manager cannot play the role of client advocate, because they are concerned about a schedule and budget. A software engineer cannot play the role of client advocate, because they are concerned about how the software will work, not how the people that will use the software will work. A software builder cannot play the role of client advocate, because they are concerned about coding.
-
-	As a software architect, you must have you feet planted firmly in both worlds. One foot must rest in the client’s world of business problems and opportunities. The other foot must rest in the builder’s world of software problems and opportunities. You must either be a business subject domain expert, depend on someone else who is, or make yourself one for a given architectural project. You must either be a software subject domain expert, depend on someone else who is, or make yourself one for a given architectural project. Perhaps you must be some degree of all of these. Remember: you are one that the client is depending one to see the bigger picture.
-
-	With my feet firmly planted in both worlds: business and software, taking on the role of client advocate and software builder to bring larger and larger software components together to create a harmonious whole, I've never had a problem getting work done with the technology at hand; whether the hardware is main-frame, mini-computer, or microprocessor; whether the operating system is MVS, UNIX, Linux, or Windows; or whether the programming language is procedural or object-oriented.
-
-	I've only encountered problems with people coming to a consensus of what needed to be done in the first place. So concentrate on getting a consensus to start and everything else will fall into place.
-
-	By [[Donald J. Bales]]
-
-	This work is licensed under a
-	[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
-
-	Back to [[97 Things Every Software Architect Should Know]] home page

Rmonson at 07:04, 6 July 2008

2008-07-06T07:04:47Z

←Older revision		Revision as of 07:04, 6 July 2008
Line 1:		Line 1:
		+	==There are no technical problems, only people problems==
		+
	As a software architect, you must play the role of client advocate. Your primary mission is the see your client’s vision through to fruition. A project manager cannot play the role of client advocate, because they are concerned about a schedule and budget. A software engineer cannot play the role of client advocate, because they are concerned about how the software will work, not how the people that will use the software will work. A software builder cannot play the role of client advocate, because they are concerned about coding.		As a software architect, you must play the role of client advocate. Your primary mission is the see your client’s vision through to fruition. A project manager cannot play the role of client advocate, because they are concerned about a schedule and budget. A software engineer cannot play the role of client advocate, because they are concerned about how the software will work, not how the people that will use the software will work. A software builder cannot play the role of client advocate, because they are concerned about coding.

Balesd at 20:36, 5 July 2008

2008-07-05T20:36:30Z

←Older revision		Revision as of 20:36, 5 July 2008
Line 1:		Line 1:
-	~~I've never had~~ a ~~problem getting work done with~~ the ~~technology at hand~~.	+	As a software architect, you must play the role of client advocate. Your primary mission is the see your client’s vision through to fruition. A project manager cannot play the role of client advocate, because they are concerned about a schedule and budget. A software engineer cannot play the role of client advocate, because they are concerned about how the software will work, not how the people that will use the software will work. A software builder cannot play the role of client advocate, because they are concerned about coding.
-	~~Whether it be main-frame, mini-computer~~, ~~or microprocessor~~.	+
-	~~Whether it be MVS~~, ~~UNIX~~, ~~Linux, or Windows~~.	+
-	~~Whether it be procedural or object-oriented~~.	+

-	I've only encountered problems with people coming to a consensus of what needed to be done. So concentrate on getting a consensus to start ~~with,~~ and everything else will fall into place.	+	As a software architect, you must have you feet planted firmly in both worlds. One foot must rest in the client’s world of business problems and opportunities. The other foot must rest in the builder’s world of software problems and opportunities. You must either be a business subject domain expert, depend on someone else who is, or make yourself one for a given architectural project. You must either be a software subject domain expert, depend on someone else who is, or make yourself one for a given architectural project. Perhaps you must be some degree of all of these. Remember: you are one that the client is depending one to see the bigger picture.
		+
		+	With my feet firmly planted in both worlds: business and software, taking on the role of client advocate and software builder to bring larger and larger software components together to create a harmonious whole, I've never had a problem getting work done with the technology at hand; whether the hardware is main-frame, mini-computer, or microprocessor; whether the operating system is MVS, UNIX, Linux, or Windows; or whether the programming language is procedural or object-oriented.
		+
		+	I've only encountered problems with people coming to a consensus of what needed to be done in the first place. So concentrate on getting a consensus to start and everything else will fall into place.

	By [[Donald J. Bales]]		By [[Donald J. Bales]]

Balesd at 19:39, 27 June 2008

2008-06-27T19:39:59Z

←Older revision		Revision as of 19:39, 27 June 2008
Line 4:		Line 4:
	Whether it be procedural or object-oriented.		Whether it be procedural or object-oriented.

-	I've only encountered problems with people coming to a consensus of what needed to be done.	+	I've only encountered problems with people coming to a consensus of what needed to be done. So concentrate on getting a consensus to start with, and everything else will fall into place.

	By [[Donald J. Bales]]		By [[Donald J. Bales]]

Balesd: New page: I've never had a problem getting work done with the technology at hand. Whether it be main-frame, mini-computer, or microprocessor. Whether it be MVS, UNIX, Linux, or Windows. Whethe...

2008-06-19T15:59:16Z

New page: I've never had a problem getting work done with the technology at hand. Whether it be main-frame, mini-computer, or microprocessor. Whether it be MVS, UNIX, Linux, or Windows. Whethe...

New page

I've never had a problem getting work done with the technology at hand.
Whether it be main-frame, mini-computer, or microprocessor.
Whether it be MVS, UNIX, Linux, or Windows.
Whether it be procedural or object-oriented.

I've only encountered problems with people coming to a consensus of what needed to be done.

By [[Donald J. Bales]]

This work is licensed under a
[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]

Back to [[97 Things Every Software Architect Should Know]] home page