SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 4622|回复: 2

[推荐] 开发企业架构的实用指南

[复制链接]
发表于 2012-4-23 13:57:01 | 显示全部楼层 |阅读模式
本帖最后由 技术狂人 于 2012-4-23 14:12 编辑
7 ^, g9 q) x5 V/ O8 b/ i# p' U8 |4 e+ y
企业架构是业务及其支持数据、应用程序和 IT 基础架构的逻辑组织,为未来的业务成功明确定义了目的和目标。典型的架构由展示业务的各个方面如何关联的一些图或模型组成。例如,组织结构图是表示业务单元如何相互关联的模型。
2 @1 M, E7 h  J; Z
% W1 V$ J+ b4 @! ]9 O企业应该有一个代表其当前状态的 “原样” 架构,并且有一个规划架构,以显示在未来一年至五年的业务方向。4 w2 N! U" G2 e. a
企业架构应该协调以下关键领域。请注意每个领域中的示例:
7 B1 b% o0 B* t3 b, ]' i
  • 业务:流程、战略、组织结构图和职能
  • 信息:概念性、逻辑和物理数据模型,显示需要哪些信息,以及如何与其他信息(比如客户和订单)关联
  • 应用程序:应用程序组合、接口和服务
  • 基础架构:网络概念图、技术参考模型
    : T3 `( _% l" S. R6 i4 R
为了实现协调一致,需要从每一个关键领域的视角对其进行建模,然后从各个角度链接模型。例如,从业务的角度对业务流程建模。不包括应用程序等内容。然后,将业务流程链接到支持它们的应用程序,这样就可以帮助您实现协调一致。我们这样做是为了确保每一个决策都是根据业务需求制定的,因此,应用程序并不会规定业务流程的设计方式。
  X4 T/ J. @1 o本文假设您有一个建模工具,可以用该工具创建您的架构。本文中特定于实现的信息以 Rational System Architect 为基础的。
8 \4 V; U8 Y: _, u  e9 E1 n& r1 [“我们打算做架构......我们要做架构!”
! u2 U9 u3 z& c, B* t4 n. H, f( f3 [! Z
图 1. 如果您没有一个目标,您的项目将会失败' f3 x: v# i; I: h% Q
9 o- c5 {- H" @- u0 O* k1 }
确保您的架构失败的最简单方法是毫无目的地制定架构。我已和数百家客户合作过架构项目。当项目没有成功时,我问他们为什么要创建企业架构。他们回答:“因为我们想要一个架构!”
* R6 \9 w2 a( a& N% }
- k6 O+ Y4 q( @8 j! s5 Y
) Q3 P- c- ^% p3 P, a
第 1 步. 确定架构的目标" n0 f+ E* W% C8 x0 w' e6 c, t
您可以通过询问以下问题来定义架构的目标:
- {0 Q- c+ N3 d% s% x5 o2 G" ~

    * i( J6 h8 }5 E3 r# _8 b# l6 v+ k) M# Q9 z2 e2 K% O7 K( z

    # O  k( v: h7 [" W
    8 j" P0 X6 S: ~, C: s9 W% b
    • 哪些信息对于架构是重要的?
    • 支持分析和决策需要多少细节?
    • 谁将生成或使用架构?
    • 架构的预期投资回报率是多少?
    • 维护的考虑因素是什么?
      1 U6 L  H! {8 e4 `( }3 y3 p
如果您无法回答这些问题,您的架构项目很可能会失败。如果没有目标,您可能会浪费几个月来绘制没有人关心的业务流程图。或者您可能绘制了一些复杂的应用程序接口图表,但无法提交给高级管理人员,因为这让他们感到头疼。
5 _4 \0 z$ K) p: @" @. a: u以一家连锁酒店为例,将酒店经理确定为 EA 的受众。
3 ]# `) N8 X+ @' D7 p4 i+ }5 l' m$ V" O" y2 f

" o6 L8 O& ^/ q; @& B/ X9 W) }通过了解架构的目的,您可以确定必需的模型和所需要的数据的范围,从而确保人们使用您的架构进行分析和制定业务决策。* f3 t7 Z0 q  h5 M9 B
首次涉足架构时不要走极端。即使您拥有一个非常大的经验丰富的团队,您也无法捕获有关组织的所有信息。 " O( U- F3 w/ R8 }8 o) }
同样重要的是,请记住,全面的架构可能会混淆重要的事项。例如,如果只有 50 个业务流程对您的业务是至关重要的,捕获 5000 个业务流程就是没有意义的。识别您的关键业务问题,并使用它们成为您的第一个架构项目的重点。
$ Q5 {: Q, o7 i1 Y# U/ Q# u( x
1 ~5 p0 F$ A+ @! b  P; O& C/ v图 2. 架构为回答问题提供了一条路线
, n. }! k* F/ U9 C# ]2 z3 T2 V ) F! m3 H. J: j7 v0 U2 b

; u$ Q& q. k& o

0 z  {8 X5 I2 i# {6 d6 E9 r4 ^第 2 步. 确定业务问题5 G( K$ n0 v: ~& E  f# B+ P4 X
我与客户做的第一件事,是讨论对其业务至关重要的一些问题;然后我帮助他们确定哪些是他们难以解决的问题。许多客户都需要回答以下问题:; w0 Q* ~5 ^$ u7 Q* Z2 _& f$ f
酒店做架构的目的是改善入住登记和退房的体验,使他们能更具竞争力。1 q! {7 V  y: p% ^- H9 ~% a

: t3 c! c* G8 O8 U8 O
6 V, M6 j6 E* r, o
  • 不使用某个应用程序的影响是什么?
  • 某个位置迁移的影响是什么?
  • 需要使用哪些应用程序来支持业务流程?
  • 更换服务器的影响是什么?
  • 需要制定什么流程来支持新的战略?
  • 在我们的应用程序组合中,存在哪些不足或重复现象?
    7 w. _1 E) t9 G) S% r! X$ x8 M
您的问题将促进架构内容的形成。如果大多数问题都涉及您的应用程序组合,那么您需要将重点放在定义应用程序领域。如果需要了解流程如何支持一个新的战略,那么应该将重点放在业务领域。然后,就可以开始通过新的业务问题拓展架构的范围。
! P& }1 ~$ m; J

4 o, j4 p' k2 ?) p* k第 3 步. 确定假设和业务规则& Q& E2 H- A/ w1 L
0 F& D0 P8 W  g. E
现在,您已经确定了受众、目的和问题,然后应该确定用来限制或解释关注领域的业务规则。9 @6 p3 ^( ~" E9 k
每个业务都有规则。例如,如果您打算捕获关键业务流程的信息,则必须捕获该流程的所有法规或企业标准。举个法规方面的例子,健康保险流通和责任法案(Health Insurance Portability and Accountability Act, HIPAA),该法案保护工作变更的人的健康保险的承保范围。然后将创建一个企业规定,显示该公司是否满足 HIPAA 的要求。
! P3 H4 e, ~0 v* X/ `0 |您应该捕获与架构有关的假设,如 “新应用程序的信息将在周五上传” 或 “每一个业务单元都要负责记录业务流程”。
( ^/ v+ g) Z( \3 C

- P) x) D  M: j: X1 |3 L% w4 F' o
2 `4 [4 r1 ?) [: ~6 `第 4 步. 确定框架, `* t; U8 q# P( Z
- x- ^# Y& b: v! f' y
以下行业标准框架可以帮助您创建一个企业架构:
; d+ @5 ^( A" Q$ b3 s) D& b: K/ c  w
  • ToGAF
  • Zachman
  • EA31 `6 z7 @  F" _, n/ s
  • DoDAF
    7 U' L5 F1 l. g
使用标准框架,可以为您的架构提供一个 “骨架”,然后,您可以利用它建立您的模型。; S# H8 K4 e' ~  }" F, |* J
框架还提供了一些指导,指导您了解需要根据将要使用架构的利益相关者来捕获哪些信息。它提供有关组织信息的指导,但没有为您的架构建议具体的实现。
" C. _7 v$ n' A# O' x3 BInternet 有大量关于这些框架的信息。您要选择什么框架主要取决于您的架构的目标、团队的经验,以及您是想遵循 ToGAF 这样的已定义的流程,还是仅像 Zachman 那样,帮助确定出于什么目的使用哪个模型。
* {" z0 A  q; _5 L2 ?' J2 R/ ^5 A3 D您还可以组合多个框架。TOGAF 和 Zachman 经常一起使用。
1 i: ~+ e, W9 m8 K- e7 r
2 _! D/ ^7 _6 j7 M图 3. 您的选择应以您的目标为基础,不要作出随机选择
6 ]; R! z4 o$ F( Q8 q' W
- U' S0 K& u1 B' k如何将框架融入架构?6 S' Z* V6 b1 |7 h+ S1 r
框架提供关于建模对象的指导。然后使用一些方法来创建模型。; W  r5 U) j8 h, z3 Q* g
方法是一个规则集,说明了如何对某个对象建模。例如,业务流程建模标记(Business Process Modeling Notation, BPMN)方法提供了用于业务流程建模的精确的规则和标记。9 U6 o/ u. ~( w( a3 f3 [
1 I4 A0 q! M+ [
图 4. 框架有助于确定方法的选择
, v9 b/ y% Y' n! w 7 O+ }1 j1 z' H. I* ?" \7 t
框架有助于组织架构的关键领域,并确定您需要建模的视图,比如,解决业务问题所需的角度和数据。* d9 o- s3 e' h( H8 ?$ E
连锁酒店决定使用 Zachman 框架。
! N8 {& @3 [* M! {1 N9 n6 [: r5 e2 d8 I2 E
6 R8 A& ^9 {4 o, m' R1 C
尽可能使用行业标准的方法,而不是 “内部开发” 的方法。行业标准的方法包括规则集和标准的建模方式。多数内部开发的方法无法以有用的方式捕获信息,因为​​没有明确定义的规则集,这使人们以多种方式对相同的信息进行建模。这也会影响分析,因为信息没有按照标准进行捕获。: s$ Z1 e9 V3 i# D1 X
根据需要的信息类型,可以生成多种模型来支持框架。
# f5 v  s4 l( \  H! S1 i- C4 ?
& a5 V; @! V3 L  E6 |! X图 5. 框架及所支持的方法
" E" {+ X& ?: p: g/ p0 H) r " @& A9 H9 V9 D' R# T/ K


6 C" {. A  ^/ x/ e. I! F8 w6 d  S
. F& A- u0 w3 S( M/ c, _第 5 步. 创建一个元模型
) u. C. d. J0 m0 }0 W元模型是架构的一个抽象视图。它显示您正在尝试捕获的数据以及数据之间的关系。这是您实现协调一致的地方,它以您的业务问题的解答为基础。
7 y: }& P- F5 ^2 m% f5 t3 i例如,如果您需要了解支持特定业务流程的应用程序,在您的元模型中必须存在这两者之间的关系。否则,数据之间不存在任何联系,您无法解决您的业务问题,架构也无法发挥其作用。
# G* n# {# }7 g& Q6 _& O, N请注意,在元模型中,您可能并不希望所有数据之间都存在直接关系,您应该只将存在逻辑关系的东西放在一起。例如,将组织部门与技术相关联没有任何意义,但将技术与应用程序相关联就有意义了。Rational System Architect 等良好的建模工具支持通过遍历元模型来创建复杂的报告。所以,在这个元模型示例中,您可以报告支持某项业务功能的硬件,即使两者在元模型中并没有直接关系。在元模型中,您可能从业务功能遍历到该功能所拥有的某个业务流程,再遍历到业务流程的位置,然后遍历到该流程所需要的支持应用程序,最后,遍历到支持该应用程序的技术。
7 ^6 h* `3 D, o6 U1 \
2 {) _% \& M/ g0 F; D0 A图 6. 关系(元模型)示例
  P7 t! ^4 Y) }+ a6 Z2 W2 r) }
( `9 \+ m( t) F. l0 b+ q您的元模型应该包括以下特性:* V( ^5 ~$ Y! b0 R& e8 a0 D% r3 f

    : ]9 j- ]; O+ ^, `6 |7 B; H; z

    . S7 i2 l. P. f% w* \+ x
    6 w# \: {: H& z2 j, b
    • 架构元素之间的关系。例如,业务流程和应用程序的关系。
    • 元素的定义。例如,术语 “应用程序” 的意义和您将捕获的属性。
    • 业务问题的可追溯性。例如,如果您的问题是 “什么应用程序支持什么业务流程?” 那么您应该知道,元模型中需要一个业务流程和一个应用程序,它们之间存在直接或间接的关系。
      2 V, ]$ ~- H" r- L  R; L' k7 h; ?

( v9 S3 X" f9 v  n, v
8 X# d( d9 L; D3 g0 z
第 6 步. 确定架构中所需的模型
$ }' V( t, R1 p" u% n4 T  A, G2 o7 m& A7 h- s
现在您已经确定了您的业务问题、框架以及解决问题所需的元模型,然后还需要了解要绘制什么样的模型。# N& s9 A4 m4 S$ q8 S1 k
将业务流程作为一个例子,有许多行业标准支持业务流程的建模,如 BPMN 和流程图。请根据以下条件选择您的建模方法:& C4 h( I+ A# }4 A* d6 `
  • 信息的受众。管理者理解如 BPMN 等简单的图表;软件开发人员通常喜欢 UML 序列图或用例。
  • 元模型的元素。如果在您的元模型中,您需要了解数据以及与它相关的业务流程,请考虑使用 BPMN 对其建模。相反,如果您只是担心流程步骤的顺序,请考虑创建一个流程图。
    + G0 {" R9 R, p  E
知道受众和您想建模的内容之后,您就可以确定您需要创建的图表。在上面的例子中,因为您需要有关业务流程和系统接口的信息,您可以选择以下模型:
( t# S7 {0 {; S+ B6 R. _! k
    3 N' q, c2 S% i) W0 o8 N% F

    % x# b, @/ x7 k1 J4 `$ P7 A  X9 f1 }: n3 u; B

    3 W' A8 d2 B4 t2 G& J0 ~- h, S3 l2 }
    • BPMN(捕获业务流程)
    • 系统架构(捕获应用程序)6 U& Z9 g/ ?( q8 Y, }: |$ X
以酒店为例,他们需要回答的业务问题是 “什么应用程序支持什么业务流程?”
$ W5 A/ @" B1 F& ^
& X. s2 G4 R4 o5 [& }" i" Z  N* P/ y6 F1 t
重要的是,请记住,您不能用单一图表来创建 EA 中的一切。此外,架构视图的分离是一种最佳实践,如应用程序视图与业务视图分离。如果您尝试在同一个图表中完成两个视图的建模,这样做往往会造成混乱,并且无法以有意义的方式捕获信息。7 O4 y. q6 i/ `! b
" e8 y' s) P# b3 v: f: I" _6 \
图 7. 使用模型来解决业务问题,所以架构是有用的…6 ^4 O6 p9 u% [2 M

( ~8 U: \+ n" ^$ I% p( f/ D, n, `! y

3 B5 P5 K( C4 y1 m图 8. …不要为了建模而建模" |* o/ C) u4 j1 D
3 _3 N+ W* j" t& ?- g0 x' b
正如 Will Gadd 所说,“只是出来走走,做点不那么重要的事情,这样做我就已经觉得很高兴了。”' P: |% c* x. q) G3 q
使用合适的工具
* A! Y9 \0 V2 U* Y' |单一的建模工具或方法并不能提供完整的解决方案。除了开发模式的工具之外,您也应该有发布、需求管理和仪表板显示等工具。仪表板在饼图和条形图等容易理解的图表中展示您的企业架构信息。) Z+ u# N$ }0 R& |
如果您的架构工具是可定制的,则意味着将使用一些改变工具原有用途的问题定制。大量的定制通常标志着使用了错误的工具或方法。还请记住,定制会带来架构上的管理开销。3 i7 E0 c) Z2 f
有些客户通过定制架构工具来创建自己的模型。这并不是最佳实践的方法,特别是如果 “模型” 是占满了整面墙的单一图表,其中包含了关于您的架构的所有信息,这肯定不是一个最佳实践。我们不应该创建墙纸,而是建议创建报告。并不是一切都需要在一张图上显示。
" U% v$ F1 W" L2 }! f! `在创建架构时,人和工具同样重要。一个人不可能在架构的每个方面都是专家,因此需要发展一个成熟的团队来支持架构。关于架构团队的理想特性的列表,请参阅本系列的第一篇文章,从您的企业架构顾问身上获取最大价值
/ e( i9 O0 F, O/ Z/ d1 `( ]8 v

8 H9 Z8 d4 S7 s' N7 ?# t5 G- N0 X, G
第 7 步. 整合架构0 i1 O, S( H) ?/ T1 W2 r
6 |% e( [5 t- C. j' C) w+ S
将您根据之前所确定的关系捕获的数据链接在一起。无论销售人员跟您说的话有多漂亮,不要相信,一个工具是无法奇迹般地做到这一点。此外,如果没有一个资料库,关系的链接真的很难做到。如果有人建议说该项目可以使用电子表格做到这一点,那么寻找另一个项目可能会是一个明智的决定。
9 [+ f4 `0 {9 t1 ^  Z如果您现有的项目或业务线已经有架构,并且您想创建一个企业架构,那么最简单的方法是自下而上填充您的 EA。采用现有架构,并将共同的元素放进一个资料库中。具体而言,可以尝试标准化整个组织中使用的模型和术语,因为可能每个人都对同一个组织使用同一个名称,比如,不是同时使用 “财务部”、会计或财会等别名,而是将它们标准化为 “财务”。
/ E& u3 H/ @# x/ S. z如果这是您的第一个企业架构,那么请在整个组织中使用一个公共的蓝图,使用与企业架构相同的框架、术语和模型为业务线创建一个架构。这样,您就可以报告整个业务。
; _& y# R- n* t分析架构
* ~; @2 n% C" J% Q3 S  K$ X( s! X1 }. d# k  {. k; @
图 9. 为分析节约能源!
& U+ V5 M* F% p. t+ t' Z : c6 z* u6 Z$ e" p8 i% s  Q
如果您不愿意花时间来分析架构,可能就不会去分析它。如果不分析它,那么为什么要构建它呢?在时间表中,这关键的一步常常被忽视。至少应该将 50% 的模型开发时间分配给分析,这包括审查模型以验证和确认它。! v' X! R; J1 {, c/ P
然后执行定量和定性分析。此时数学很重要,在显示投资回报率时尤为如此。如果您使用行业标准方法(如 BPMN),则可以使用定量分析来显示缩短流程、节省时间、节省成本和消除冗余中的瓶颈。 BPMN 是 “结构化” 的,因为它有一个您不能违反的规则集。这些规则确保您可以执行分析,比如分析模拟业务流程的变化,看看该变化是否能够节省时间或金钱,或者是否会造成瓶颈等负面影响。. T) ?' U2 F2 G! j4 l7 G) H
通过查看模型,可以找出潜在的问题所在,然后完成定性分析。例如,如果您有一个业务流程反馈到流程的早期阶段,那么这通常标志着该流程必须返工。消除流程中的反馈回路是改进流程的一种方式。
+ |4 I0 ^' D2 N# R完成分析后,就可以与他人共享成果。如果人们学会了如何使用架构,就会看到它的价值。报告在这里是关键,所以在选择企业架构工具时,请确保它提供了强大的报告功能。
! x$ T& x$ Q, H2 R7 T7 s+ r不要忘记,您需要一个游戏计划* ~. b6 y1 G: I1 S
9 L0 ?) ~/ L' I- L! Y! m) n! R
图 10. 制定您的 EA 游戏计划
7 V  F0 A, Q3 a5 B0 h
$ D5 H( W) v; [4 ^8 Q7 g人们常常忘记,需要在解决了许多管理问题之后,才能启动和支持 EA 项目。需要解决的一些管理问题包括:. h% m" ^& u% X: m8 I
  • 如何部署企业架构?
  • 在哪里部署它(Web 站点,等等)?
  • 谁是团队成员?
    : g5 l" f5 u8 D" y6 `" r( Z) |! O  |
    • 审查委员会
    • 项目管理
    • 行政管理% ?% T+ `" J' I2 c' \2 @( j, x
  • 谁将使用信息?
  • 谁将可以访问信息?
  • 将要遵循什么标准?/ u2 I! a" j, v, d# w
    • 命名约定
    • 颜色编码
      " a, V* c2 \; ^6 c
团队里有一个 "EA"
7 Q% t$ g; J% I. t' p# r% v8 `) D+ ^; Z( z6 F- g' b
图 11. 良好的 EA 团队确保成功# x% z1 R$ v& G7 o, l

7 L9 S' v: O! U您不能凭空创建架构。您必须做好准备,与 EA 团队以外的人合作,否则用户无法采纳和使用您的架构。此外,您还要确保利益相关者(例如,付钱让您构建架构的人,或者帮助您构建架构的人)参与了您的决策。
, l4 O: c1 M2 ~" r, [! T治理是制定决策所必不可少的。治理有助于定义您将在架构中使用的规则和战略。以组织中的业务线命名的治理为例,人们可能不希望出现某人将这个部门称为 “会计” 而其他另一个人将它称为 “财务” 的情况。治理也决定了哪些模型已准备好发布为 “批准”。成功的 EA 所需要的典型委员会包括:; p; d: n; Y; s8 v& L1 B

    5 |( V+ c: c* _2 R5 G
    8 s* E* c' _1 M" j8 I0 C6 z# [
    3 O' |5 e* i: l" {4 W7 j/ B  m: H5 h& O
    • 架构审查委员会
    • 配置和控制委员会
    • 管理指南(例如,谁可以创建模型,审批流程的什么,变更请求的流程是什么)
      : z. I4 d$ M' z
越多人参与支持架构,使用该架构的机会就会越多。9 ]# u8 N: n7 Z9 o$ b
最后几点建议+ v. n5 n/ ?( _, }- Q' B" {  o
如果建立架构看起来很难,那是因为它的确很难。但这也表示您在以下其中一个方面犯了错误:
& p% Q8 `7 s* s) J0 ?8 Y

    , r# \" q" e8 r# L- s9 S$ f# d& `" r$ n3 p

    ; Y. M8 @, U3 s% U9 b5 v$ N4 l. [
    • 模型。例如,使用一个 BPMN 模型来捕获应用程序界面。
    • 利益相关者。例如,不熟悉业务流程的人提供输入或反馈,而不是由真正做流程的人来提供这些信息。
      ! p7 R9 L' \( _7 S8 D0 R+ y
学会从架构中将政治原因分离出来# G4 @2 T; B- f0 d+ i
    4 S" {# l  O, v7 g% _; D2 S9 X

    5 i0 S" y# O; ~! \3 v( L. I5 ~
    7 e% j- m2 Q/ f6 J6 j8 V
    ! y& b9 n" @6 f; {! l
    • “不要记录那条信息,否则人们会知道我们做错了!” – 这是对企业架构的一个常见反应。但是记录理想化的视图是没有意义的,因为您无法规划未来纠正问题的方式。
    • “我的组织正在使用不同的方法捕获我们的架构。” – 在我合作过的每一个组织中,总会有一个业务线不希望以标准的方式开发他们的架构。没有人是特殊的。没有人有不以标准方式做事的正当理由。处理这种情况的最佳做法是培训那些希望与众不同的笨蛋。如果他们对期望的目标感到满意并了解他们的期望,那么他们会愿意遵循标准。如果这个方法无效,那么您惟一的选择就是打断他们的腿。. c$ H* n* ~. ^, F7 ]4 L0 g
使用架构打破独裁& A6 |2 _3 @" z) m* a3 E% u
    $ Q% V! A" c3 q6 y) x! B

    + m7 ~# F: p& i4 g! J; @2 i/ W# a2 {  F  Z4 A5 K; N/ |# N" ]3 [
    / {( q" ]+ A+ l4 ]2 A
    • “我们没办法跟那些家伙沟通,您知道,他们是做软件的。” – 在大多数公司都有些人认为与软件开发人员谈话是一种挑战。在您了解他们后,就会发现他们其实都是一些好人。并且,如果他们发现可以用简单的方式与您沟通,可以使用图片,而不是无意义的 500 页需求文档,那么他们对您的态度也会随之改变。
    • “我倒是愿意把数据给您,但我需要先与我的管理层确认一下。我下次再回复您好吗?” – 有些人认为隐瞒信息可以保住工作。如果 Barney 是惟一了解您的应用程序如何连接在一起的人,那么您就不能解雇他。其他业务线可能不希望共享信息,因为他们怕您用这些信息来解雇员工。通过解释将要采用哪些信息,以及如何让提供信息的人从中受益,可以处理这些情况。如果您带着不可告人的目的(如,解雇员工)来使用信息,那么您会看到愿意向您提供信息的人数会急剧下降。, a; n  C# u( p* ?

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
 楼主| 发表于 2012-4-23 13:59:11 | 显示全部楼层
回复 支持 反对

使用道具 举报

发表于 2012-5-23 08:38:48 | 显示全部楼层
在天愿作比翼鸟,在地愿作同圈猪!
/ m+ A4 i% R# w% F: ~) P3 O% i! v* j
8 K4 x! @, l5 h  T) K; v  \嘎嘎
0 @, V% c9 r. h: ?. K2 M! }; O
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

SCMLife推荐上一条 /4 下一条

QQ|小黑屋|手机版|无图版|SCMLife.com ( 京ICP备06056490号-1 )

GMT+8, 2018-6-21 01:13 , Processed in 0.075613 second(s), 6 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

快速回复 返回顶部 返回列表